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,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)) Date: 1996/11/19 Message-ID: #1/1 X-Deja-AN: 197431076 references: <325BC3B3.41C6@hso.link.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-11-19T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Nope, I don't buy that for a moment. By that reasoning, A.3 A(3). >3 The implementation shall ensure that each language defined subprogram is >reentrant in the sense that concurrent calls on the same subprogram perform >as specified, so long as all parameters that could be passed by reference >denote nonoverlapping objects. > > >would be entirely redundant, since according to you, it is implicit in the >specs of the routines. Actually, I think it *is* redundant, and I had a big argument about that with Tucker. (I think it should have been a NOTE or an [bracketed-in-AARM] thing.) The reason it's there is that some Ada 83 compilers failed to make things like Text_IO work properly. And because Tucker wanted it there. This is like many real-life laws -- legislatures are continually passing laws that are just special cases of existing laws, because somebody is griping about a rash of some particular crime. Legislatures don't normally sit around thinking of every possible evil, and pass a law against it. RM authors, on the other hand, try to do something like that. ;-) >In fact it is perfectly possible to do things with the defined procedures >that definitely ARE erroneous, for example, surely you dont think that >two tasks that modify the same string at the same time must work >correctly. No of course not, that we would expect to be erroneousw. Agreed. >"behave as if they are really (varying length) strings" >is meaningless, either we ignore the parenthetical remark, in which case >it is nonsense, since these do not behave like Ada strings, or we include >it, in which case we are talking about something not in the language and >so are defining varying length string semantics in terms of varying >length string semantics which is nonsense. Whenever the RM uses a term that it doesn't define, which is quite often, you have to take the most reasonable meaning you know from plain English, or from general computer jargon. Perhaps I interpret this section using a "friendly reading". I'm not going to worry about it until some compiler vendor tries to get away with making things erroneous that shouldn't be. And you still haven't answered my main objection to your reading -- if you read it that way, then why isn't practically everything in Annex A erroneous? And lots of other stuff. E.g: X, Y: Calendar.Time := Clock; X := Y; -- Erroneous? (No tasks here.) How do we know that the implementer has not evilly made the full type for Time controlled, with an Adjust routine that does something erroneous? Or raises GNAT.Evil_Exceptions.Whatever_Error? Or writes the value 17 into all integer variables in the program? We know that, because the correct way to interpret the RM is that if it doesn't say any of those bad things happen, then they don't. The same way we know that 1+1 of Integers doesn't have side effects. (Of course I know that two tasks modifying X at the same time would be erroneous. That's covered by 9.10.) - Bob