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: <4kcer3$mi4@solutions.solon.com>#1/1 X-Deja-AN: 146455520 references: <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> 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 <4kbrt5$k3h@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote: >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. Yes, they are. There is no portability problem in the C language, or the behavior of read(). It is not a portability program for a mistake to behave randomly or differently on different machines. >>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. No, they define the boundaries of a language; things beyond that boundary are *supposed* to be undefined. Since no program in the C language ever runs into that behavior of a C implementation, it is not a portability problem. >>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. Any program which does that is not a C program; it has left the bounds of defined behavior. Further, that behavior is a flat out bug; it is never correct, and the portability problem lies in the program, not the language spec. The program needs to be fixed. >>(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. It's a portability problem if you write that broken code; well, don't do that then. No point blaming the language for incompetent or foolish programmers. -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