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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: seebs@solutions.solon.com (Peter Seebach) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/08 Message-ID: <4kb2j8$an0@solutions.solon.com>#1/1 X-Deja-AN: 146354729 references: <4k9qhe$65r@solutions.solon.com> organization: Usenet Fact Police (Undercover) reply-to: seebs@solon.com newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-08T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Peter said >"Now, as it happens, Linux does do the right thing - if I define my own >read(), I get *my* read any time I call read, so the implementation is >conforming." >Boy, this sure has wandered! True enough. The above is the only ANSI related issue. >THe original issue was the semantic behavior >of read. Unlike other unices, in Linux, the bounds check for the read >buffer is based on the requested count, rather than the actual count >of data bytes read. It is hard to say either approach is right or >wrong, but they are different enough to cause portability problems. How? No offense meant, but any code which can be affected by this is flat out broken. POSIX-style read is to be given a pointer to at least nbytes of space, for the information read. Period. No correct code can ever be affected by the behavior of read when nbytes is larger than the size of the buffer. (For latecomers, the question is what happens if you *KNOW* that the file only has, say 100 bytes left, so call read with a 100-byte buffer, and nbytes==256.) I can't see how this is a "portability problem" any more than it's a portability problem that some systems will crash on printf("%s", (char *) 0); ... (SunOS won't, though.) Something which works only on some systems is not a portability problem *if there is no standard saying it works*. Likewise i = ++i; producing different results on different machines is not a "portability problem". If read() behaved dramatically differently with valid inputs, I would see it as a portability problem. (This applies to most of the C standard library, as well, of course. The behavior you're used to, such as "void main(void)" or "fflush(stdin)" not working, is not a portability problem, it's broken code.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html