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: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: emery@grebyn.com (David Emery) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/10 Message-ID: #1/1 X-Deja-AN: 146849756 references: <4kb2j8$an0@solutions.solon.com> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca> <829066525snz@genesis.demon.co.uk> organization: MIND LINK! - British Columbia, Canada newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-10T00:00:00+00:00 List-Id: In article , dewar@cs.nyu.edu (Robert Dewar) wrote: ... > What exactly *is* the wording of the POSIX standard here (Lawrence, you > must have it at hand, please quote it exactly). The interesting thing > is to determine whether this definition says enough to make *any* use > of read defined without appealing to "unwritten rules". I would guess > not! I checked today. POSIX.1 (1995 version) is completely silent about what happens when the count > the length of buf. I wish I brought my standard home, so I could quote it, but it says something like "read transfers count characters into the buffer pointed to by buf." The standard is completely silent about the characteristics of buf, and one could do some 'formal standards reasoning' that says that *any* program that depends on the relationship between buf and count is non-compliant, in that it is depending on unspecified behavior. One would have expected for the standard to say something like "the buffer pointed to by buf, which is expected to be capable of holding at least count bytes..." Oftentimes, POSIX is deliberately silent in some areas, particularly error handling, because there was no consensus on behavior. Thus any behavior is "undefined", and any implementation is 'conforming', regardless of what it does. Personally, I think it's very poor standardization practice to be silent in such cases, I'd much prefer the standard to explicitly specify such behaviors as 'undefined', to warn the user. In this case, I would have preferred for POSIX.1 to say "If the size of the storage area pointed to by buf exceeds the value of count, the results of any transfer into buf is unspecified." Additionally, there is no explicit error code identified for "too much stuff in the buffer". But POSIX.1 permits implementation extensions in such a circumstance, so the Linux implementation is perfectly conforming, as are implementations that blindly write into some other address space and implementations that detect the fault and immediately send email to CJIII and his lawyer :-) (Even in Ada, writing past the end of an array using unchecked programming can result in any sort of behavior, including trashing the boot track of the system disk....) dave