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,e8c8d1c63ffacf0d X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Constraint checking of actuals passed to Attributes Date: 2000/05/10 Message-ID: #1/1 X-Deja-AN: 621573711 Sender: bobduff@world.std.com (Robert A Duff) References: <391250A8.99D1585C@hotmail.com> <39171B69.2F983487@averstar.com> <8f93lm$1es$1@nnrp1.deja.com> <8f9snr$vbr$1@nnrp1.deja.com> <8fai9a$n7n$1@nnrp1.deja.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-05-10T00:00:00+00:00 List-Id: Robert Dewar writes: > Now wait a cotton pickin moment (is that the way that phrase > is spelled? :-) > > What does the RM say: >... You asked me about the *intent*. I don't claim that the RM precisely specifies the intended rules, so you're quoting of the RM is irrelevant. I do claim that the intent should be clear, at least for simple things like integers, to someone who doesn't use an overly legalistic reading of the RM. After all, you argue that the RM wording has the same effect as the Ada 83 wording. Clearly, if that were the intent of the language design team, then we would have left the wording as in Ada 83, because it's much simpler wording -- it just says that using an uninit scalar var is erroneous. We must have intended to make *some* change, since we introduced new terminology ("invalid", "abnormal"), and new rules. > That's why I dislike this business of divining intent so > intensely. You end up asking the design team what they remember > having in mind, and they may not even remember correctly. It is indeed possible that I don't remember the intent correctly, or never understood it correctly. > This is perfectly predictable, quite reasonable (think about > NaN's in floating point, and ENTIRELY allowable from the quoted > paragraph read in the most friendly form possible). Yes, NaN's are part of the reason the "intent" is so hard to specify precisely, which is why the RM doesn't try. > Similarly if I was on an IBM 7040, then it would be free to > cause a fatal parity error terminating the program on any > access to an uninitialized variable, and that would be just > fine too (again, very NICE behavior, at least during the > testing phase). ... I believe the intent was not to allow such abrupt termination of the program. I agree that's "NICE behavior". I've always thought Ada should have a notion of killing a program (like "exit" or "abort" in C) stronger than exceptions. But it doesn't, and there was no mandate to add such a notion in Ada 9X, so the only possible way of notifying of errors is to raise an exception. >... The WATFOR compiler used to do this (it used > the hardware diagnostic instruction to set parity wrong on > all uninitialized data). ASIDE: You have to be careful about these low-level hardware-oriented implementations, because they might not match Ada's notions. For example, in Ada, it is perfectly OK to copy an array full of uninitialized components, using an assignment statement. If the hardware complains about that, then it's wrong. I learned this when writing an Ada compiler for the Symbolics Lisp machine, which had a 4-bit tag on every word, and there was an "undefined" tag, and it detected any load of an undefined word. But we had to disable that (by zeroing uninit vars), which was kind of sad. > It was my understanding that we put the words implementation > defined in that paragraph precisely to allow a variety of > possible implementations, all of which are reasonable. Perhaps, but if doing so allows absolutely anything, then we made a mistake (ie, we didn't write words precisely defining our intent). We certainly did not intend to allow the use of an uninit var as an array index to trash arbitrary memory locations. I realize that some reviewers didn't like that (Bevin Brett, for example, thought the trade-off should be in favor of efficiency). - Bob