comp.lang.ada
 help / color / mirror / Atom feed
* Allocators and the requirement to raise `Storage_Error`
@ 2013-05-03  5:35 Yannick Duchêne (Hibou57)
  2013-05-03  7:31 ` egilhh
  0 siblings, 1 reply; 5+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2013-05-03  5:35 UTC (permalink / raw)



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

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-05-03 23:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-03  5:35 Allocators and the requirement to raise `Storage_Error` Yannick Duchêne (Hibou57)
2013-05-03  7:31 ` egilhh
2013-05-03  8:36   ` Yannick Duchêne (Hibou57)
2013-05-03  9:33     ` Yannick Duchêne (Hibou57)
2013-05-03 23:17     ` Randy Brukardt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox