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: 146545092 references: <4kb2j8$an0@solutions.solon.com> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca> 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: Kazimir said: >This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a >pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and >until now I have been completely oblivious to this difference between Linux >and other systems. The spec of an interface does not depend on what "wouldn't even occur" to Kazimir, it must be independently defined. >Unfortunately, I could not find anything in POSIX.1 that would explicitly >disallow this. The document is not very assertive in defining undefined >behavior. I'm going to check it once again in case I missed something. This is not a matter of defining undefined, it is a matter of defining the requirement on the length of the read buffer, and it is truly amazing to me that none of the references at hand, not even the POSIX document, specifies this. >It's not surprising: you lied to the read() function. But you are right, you >can't tell this from the definition in POSIX.1 or from typical manual pages. Sorry, this is wrong, I lied to the *implemention* of the function as it occurred in Linux. Now it is true that the spec of the function is different in Linux than in other systems (you quoted the manual pages that showed this clearly). So of course we have a portability problem here. Read is different in different systems, not only at the implementation level, but at the spec level. The program in question was correct with respect to the spec on "other systems": >I checked the manual pages for read() on several systems. Linux documents >that results if the buffer pointed at by buf is outside of the address space >of the process. On other systems, it is claimed that EFAULT results if >the buf pointer is directed outside of the address space. Kazimir, perhaps you don't understand the whole idea of specs, but that quote means that code that makes sure that the pointer is directed inside the address space is OK if the buffer is not overrun! >There are certain unwritten rules, though! That's the totally unacceptable viewpoint that is at the center of the concerns in this thread (the details of read are uninteresting). The trouble is of course that Kazimir's unwritten rules are clearly different from other unwritten rules. I think one of the most essential things to understand in programming is the importance of abstracting specifications from implementation. Comments like the above (unwritten rules) one show that there is a long way to go! >What prevented the code from advertizing the true buffer size of 100? >In any case, it doesn't sound like a case of ``defensive programming''. Whoever said it was? With respect to the discussion of seperate processes adding to the file etc, this is irrelevant to the discussion of the spec difference. For the program in question, you still get a different behavior on the two systems: On Linux, you always get an exception On "other systems", you get defined behavior, and no exception, unless this unlikely external event lengthens the file, in which case you get undefined behavior. These are quite different semantics, and it is different semantics that result in one kind of portability problem. The observation about appending to the file is relevant in recommending that the count reflect the actual count expected to be read, and of course this was LONG ago corrected, within hours of finding the Linux behavior, so I can't show you the incorrect code. But the fact remains that we have a portability problem which SHOULD be cleared up by POSIX (or perhaps by SPEC1170), but apparently is not mentioned by POSIX< and I am willing to bet that SPEC1170 is similiarly vague. The standard of precision in defining specs of routines at this level is generally appalling.