Allocators and the requirement to raise `Storage_Error`

Allocators and the requirement to raise `Storage_Error`

[Yannick Duchêne (Hibou57)]

ARM 2012 @4.8 says:

http://www.ada-auth.org/standards/12rm/html/RM-4-8.html
> For an allocator with a subtype_indication, the
> subtype_indication shall not specify a null_exclusion

This may be interpreted as “null may be returned by an allocator”.

ARM 2012 @13.11 says:

http://www.ada-auth.org/standards/12rm/html/RM-13-11.html
> If Storage_Pool is not specified for a type defined
> by an access_to_object_definition, then the implementation
> chooses a standard storage pool for it in an
> implementation-defined manner. In this case, the exception
> Storage_Error is raised by an allocator if there is not
> enough storage.

This may be interpreted as “may be a user defined storage pool” is allowed  
to return `null` when there is not enough storage in the pool.

ARM 2012 @13.11, again, says:

> If Storage_Pool is specified for an access type, then if Allocate
> can satisfy the request, it should allocate a contiguous block of
> memory, and return the address of the first storage element in
> Storage_Address. The block should contain Size_In_Storage_Elements
> storage elements, and should be aligned according to Alignment.
> The allocated storage should not be used for any other purpose
> while the pool element remains in existence. If the request cannot
> be satisfied, then Allocate should propagate an exception (such as
> Storage_Error). If Allocate behaves in any other manner, then the
> program execution is erroneous.

So finally, in no case at all it is allowed for an allocator, to return  
`null` instead of raising `Storage_Error` when there is not enough  
storage, even if the two quotes above had possibly provisional hope for  
the other way.

I'm disappointed with the last “If Allocate behaves in any other manner,  
then the program execution is erroneous”, which implies it's erroneous to  
return `null`.

I may understand allocations failing in a declarative part, may be an  
issue if some declarations coming next to it refers to this allocation.  
But finally, one may also define a function doing something similar and  
not being imposed this requirement, i.e. returning an access type after  
some kind of allocation and returning `null` if it fails, except it won't  
work with non‑constrained types and such a function would need to be  
defined for each constrained subtypes or derived types of the  
non‑constrained type (a pain).

I though there may be something in the RM, allowing an allocator to return  
`null`, and expect `Program_Error` to be raise instead, on any attempt to  
dereference an unallocated access.

I will review the relevant parts of the RM again for the reasons, but  
right now, I don't see why it is this way.

(yes, I know I'm playing silly things, but I have my silly reasons).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Allocators and the requirement to raise `Storage_Error`

[egilhh]

On Friday, May 3, 2013 7:35:29 AM UTC+2, Hibou57 (Yannick Duchêne) wrote:
> ARM 2012 @4.8 says:
> 
> 
> 
> http://www.ada-auth.org/standards/12rm/html/RM-4-8.html
> 
> > For an allocator with a subtype_indication, the
> 
> > subtype_indication shall not specify a null_exclusion
> 

This Ada Issue may clear things up for you:
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0104-1.txt?rev=1.4

Basically, you have an access to an access, allocated with the default value,
which is null for non-initialized access values.


-- 
~egilhh

Re: Allocators and the requirement to raise `Storage_Error`

[Yannick Duchêne (Hibou57)]

Le Fri, 03 May 2013 09:31:56 +0200, egilhh <egilhovik@hotmail.com> a écrit:

> On Friday, May 3, 2013 7:35:29 AM UTC+2, Hibou57 (Yannick Duchêne) wrote:
>> ARM 2012 @4.8 says:
>>
>>
>>
>> http://www.ada-auth.org/standards/12rm/html/RM-4-8.html
>>
>> > For an allocator with a subtype_indication, the
>>
>> > subtype_indication shall not specify a null_exclusion
>>
>
> This Ada Issue may clear things up for you:
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0104-1.txt?rev=1.4
>
> Basically, you have an access to an access, allocated with the default  
> value,
> which is null for non-initialized access values.

You're right, that's obvious. I badly understand reading that part: it was  
about the subtype of the allocated object, not of the returned access type.

I still wonder why there is no provision for an allocator to return `null`  
instead of raising an exception, when a custom function of a constrained  
subtype/type, which would provide the same functionality, does not get  
imposed this obligation.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Allocators and the requirement to raise `Storage_Error`

[Yannick Duchêne (Hibou57)]

Le Fri, 03 May 2013 10:36:22 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> I still wonder why there is no provision for an allocator to return  
> `null` instead of raising an exception, when a custom function of a  
> constrained subtype/type, […]

Read “constrained or not”, I was too much focused on my current use‑case;  
this do not need to be constrained.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Allocators and the requirement to raise `Storage_Error`

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wwh16wl5ule2fv@cardamome...
...
>I still wonder why there is no provision for an allocator to return `null` 
>instead of raising an exception, when a custom function of a constrained 
>subtype/type, which would provide the same functionality, does not get 
>imposed this obligation.

This seems like a bizarre question. Ada doesn't allow returning the wrong 
answer from an operation; it's required to return the right answer or an 
exception. The operation "new" returns an allocated object. Period. If that 
can't be done, then an exception is raised immediately.

Not doing this would hide storage exhaustion and would make it look like an 
ordinary bug. That would make it a lot harder to reason about programs (its 
very hard to reason about storage exhaustion, it formally can happen 
anywhere, even "null;"). Keeping them separate helps both debugging and 
formal tools.

                                     Randy.