Re: Controlled types and exception safety

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Probably not specifically. Obviously it depends on the implementation. I
> just looked at ours, and it does nothing at all to handle memory issues in
> Adjust. That means that the object would fail the invariants after such an
> assignment. (I didn't actually realize that; it would be better to null the
> pointer in that case...) And presumably, it would eventually access through
> a deallocated pointer. But that's all a correct (if unfriendly)
> implementation of Ada, because the object is abnormal, and any access to it
> is erroneous -- see 13.9.1. (Humm, this actually isn't as clear as it ought
> to be; one could argue that Storage_Error isn't a "language-defined check"
> (its not called that in 11.1(6)).

I think 11.5(2) can reasonably be interpreted to mean that Storage_Error
qualifies.  Certainly, that is the intent.

11.5(22) also applies, although it incorrectly talks about specific
reasons why S_E might be raised, whereas 11.1(6) says S_E can be raised
by anything at all (not just "new" and procedures and tasks).

>... But surely it is intended to be covered;

Yes, surely.

> it's hard to imagine a case that is more likely to corrupt things than
> running out of memory.

Well, I can imagine "abort", and that's just as bad (except that you can
defer aborts, but you can't defer out-of-memory).

- Bob