Re: Why no constraint error?

[stt@houdini.camb.inmet.com (Tucker Taft)]

Robert A Duff (bobduff@world.std.com) wrote:

: In article <E7G5q1.J8q.0.-s@inmet.camb.inmet.com>,
: Tucker Taft <stt@houdini.camb.inmet.com> wrote:
: >Well Bob, I believe GNAT is technically right in this one, ...

: Can you quote chapter and verse, to show where my analysis was wrong?
: (Legalistically, I mean -- ignoring issues of what's
: desirable/efficient/etc.)

I guess I agree with you, that presuming 13.9.1(10) applies, then
"deinitializing" an initialized scalar variable is a no-no.

You would have to invoke 13.9.1(11) and claim that the uninitialized
representation was so weird that it didn't correspond to a value of
the type, and hence you could legitimately propagate it on assignment
(so long as the optimizer didn't forget that the LHS is now potentially
deinitialized as well).

I think the simpler choice is to prevent initialized scalars from
becoming deinitialized, and that seems to be what 13.9.1(10) is requiring.

A subtler question is whether an assignment from an uninitialized
scalar to another uninitialized scalar can be allowed to leave the
LHS still having an invalid representation.  13.9.1(10) seems to
say "no," any assignment must leave the LHS with a valid representation
(unless the RHS is an unchecked conversion or call on an imported 
function, per 13.9.1(12)).

: - Bob

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA