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: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: fjh@mundook.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/09 Message-ID: <4kdmml$uv@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 146535812 references: <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <4kcer3$mi4@solutions.solon.com> organization: Comp Sci, University of Melbourne newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-09T00:00:00+00:00 List-Id: seebs@solutions.solon.com (Peter Seebach) writes: >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. No, it is definitely a portability problem if a mistake behaves differently on different machines. It is a portability problem, because almost every non-trivial program contains mistakes, and so if a mistake can behave differently on different machines, that means that almost every non-trivial program will behave differently on different machines. If behaving differently on different machines in ways not intended by the programmer isn't a portability problem, then I don't know what is! >>... 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. ... Oh, nonsense. Such specious definitions You're trying to define the problem away, but the 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. Oh, nonsense. Such specious definitions belong in an ivory tower, not in the real world. You're trying to define the problem away, but the problem is a very real problem which has very real costs. >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. No, the portability problem is the different behaviour of the program, when run on different systems. It does not "lie in" the program -- it makes little sense to speak of behaviour "lying in" a program. The behaviour is not something that has a single cause -- rather, it has a multitude of causes, some direct, and some indirect. The problem is caused by the program AND by the implementation AND by the language spec. Of course, you can't really assign blame to any of these abstract entities; blame, if it is to be assigned, must be assigned to the people who wrote them. But you can't blame any of them too much. You can't really blame the language designers or language committee much; after all, they were just doing their best to specify the language in a way which allowed implementations some flexibility. You can't really blame the implementors, even though they may have known that defining things the way they did might lead to portability problems; after all, they were only following the spec! And you can't really blame the programmers too much for making the occasional mistake; after all, they are only human!! >No point blaming the language for incompetent or foolish programmers. Every programmer has done something incompetent or foolish at some time. Programming language design should take this, amoung other things, into account. -- 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.