* 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
* Re: Allocators and the requirement to raise `Storage_Error`
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)
0 siblings, 1 reply; 5+ messages in thread
From: egilhh @ 2013-05-03 7:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Allocators and the requirement to raise `Storage_Error`
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
0 siblings, 2 replies; 5+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2013-05-03 8:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Allocators and the requirement to raise `Storage_Error`
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
1 sibling, 0 replies; 5+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2013-05-03 9:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Allocators and the requirement to raise `Storage_Error`
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
1 sibling, 0 replies; 5+ messages in thread
From: Randy Brukardt @ 2013-05-03 23:17 UTC (permalink / raw)
[-- 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.
^ 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