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/24 Message-ID: #1/1 X-Deja-AN: 198482564 references: <325BC3B3.41C6@hso.link.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-11-24T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >And of course it is quite clear that two writes to the same file using >Put_Line with a file argument are NOT covered by paragraph 3. So that's >mightly curious: > > Put_Line (Standard_Output, "xxxx"); > >appearing in two tasks is not covered, and could be erroneous, but > > Put_Line ("xxxx"); > >is OK. That seems quite weird to me, ... Agreed. In my opinion, both of the above should be considered erroneous. I said that in another article, and I also admitted that the RM doesn't clearly say so. As you say, if one thinks the above should work, then one needs to worry about the granularity of interleaving. >... though I see how paragraph 3 could >be read this way. >Without paragraph 3, I have no idea why Bob Duff thinks that the language >has anything to say about either of these cases. I think you're confusing what I said with what somebody else said. Two simultaneous Put_Lines are erroneous if they are writing to the same file, but not if they are writing to two different files. At least, in my opinion, that's the way it *should* be. The glitch in the RM wording is that for the Put_Line without any file argument, there's no variable in sight -- even though we know that Put_Line("xxx") and Put_Line(Current_Output, "xxx") ought to have identical semantics. If I weren't so lazy, I tried to dig up some wording that says so, and then we would be OK -- I don't remember exactly how the no-arg version is defined. >But in this case (reference counts), people do not agree on what is >friendly. So I think it is something the ARG should pin down. Apparently. I'm surprised that you think the unprotected reference count implementation is reasonable. (Unless of course the compiler knows there aren't any tasks causing trouble.) - Bob