From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,113cbde0422b98e8 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Why no constraint error? Date: 1997/03/24 Message-ID: #1/1 X-Deja-AN: 227859139 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-03-24T00:00:00+00:00 List-Id: Robert A Duff (bobduff@world.std.com) wrote: : In article , : Tucker Taft 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