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: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/08 Message-ID: <4kbrt5$k3h@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 146413712 references: <4k9qhe$65r@solutions.solon.com> <4kb2j8$an0@solutions.solon.com> organization: Comp Sci, University of Melbourne newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-08T00:00:00+00:00 List-Id: seebs@solutions.solon.com (Peter Seebach) writes: >Robert Dewar wrote: >>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. It is clear that (a) such code is broken and (b) the fact that it has undefined behaviour causes portability problems. What you said and what Robert Dewar said are not contradictory. >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.) It is not *more* of a portability problem than `printf("%s", (char *) 0);', but the undefined behaviour of read() and printf() both cause portability problems. >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". Ha! Obviously you have never tried porting any serious C programs. >(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.) It's a portability problem AND it's broken code. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.