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: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/09 Message-ID: #1/1 X-Deja-AN: 146661242 references: <828964950snz@genesis.demon.co.uk> <4kbuebINNrho@keats.ugrad.cs.ubc.ca> <4kets3$ic0@news-s01.ny.us.ibm.net> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-09T00:00:00+00:00 List-Id: Mike notes/asks >I'm a latecomer to this dispute, but this is not smart: > > char buf[100]; > read(fd,buf,1000); > >By the way, how did all this get started? Good question, I don't particularly see any dispute here. Obviously noone ever wrote code so obviously peculiar as your above example! The exact code, which appeared in the GNAT runtime was a loop to read a file that had in the loop read(fd,p,16*1024); to read the file in chunks of 16K. The last call exactly filled the remaining buffer which had been sized to exactly fit the size of the file. This code worked fine for a long time on nearly all systems, and in fact if you read the spec should work on most systems. But it failed on Linux (and was immediately corrected, no big deal!) and the reason is that Linux has subtly different semantics. The issue was whether any of the so-called specs for read (POSIX or SPEC1170) were clear enough to determine which of the two observed implementation models was "right". Turns out that no spec we could find (no one seems to have SPEC1170) precisely defined the specs. The wandering off into whether the code involved was or was not a good idea (obviously it was not!) is irrelevant. I was just using this as an example of a portability problem caused by weak specifications. Peter takes the odd view that it is not a portability problem because the code was not well defined, and therefore not portable. This seems a bit of a useless observation--Peter has determined that only portable code is portable, not terribly useful :-). Kazimir at first claimed that the spec clearly favored the Linux interpretation, then could not find any evidence and appealed to unwritten rules :-) But just to be clear, there is no dispute over whether the code as written was a good idea, it was simply an interesting example of a portability problem resulting from weak specs. The disussion showed to an extent that surprised even me that the specs for such routines are really horribly weak, at least in POSIX.