peter@thirdi.UUCP (Peter Rowell) (04/29/87)
(See my response to Chris Torek regarding my use of the word "require" with regard to #define NULL ((char *)0). ) In article <17498@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >>In article <31@thirdi.UUCP> peter@thirdi.UUCP (Peter Rowell) writes: > .... >> This method has stood us in good stead (except when we have foolishly >> violated it) in porting a source-level debugger to over 70 different >> systems - not all of which were done by followers of the True Faith. > >Umm, err, it's not a matter of "faith", so the use of terms connoting >religion is inappropriate and somewhat irritating here. K&R is quite >clear on this matter; if somebody doesn't "believe in" K&R (or ANSI >C), they're perfectly welcome to implement some language that does >things otherwise, they're just not welcome to call it C. > Lighten up, Guy. You're taking things *way* too seriously. The quip about the "True Faith" is/was aimed at people who seem to feel that all systems/compilers which deviate from their personal concept of "correctness" should be Burned at the Stake. Whether you like it or not, there are an amazing number of products out there that are not perfect (Did Sun fix the compiler bug I reported 2 years ago? What about the ptrace bug that crashed the kernel?). If you are a software developer and you wish to market your software as broadly as possible, sooner or later you will run into *at least* one system that is the result of something less that the Immaculate Port. When you encounter such a system, you can do one of three things: 1. You can request/plead/scream/etc. at/with the machine vendor to fix it. If you wait for this to happen, you probably will be very old when the fix is available. You will almost certainly be "late to market". 2. You can decide that you want nothing to do with these cretins. If the company has a small installed base which doesn't appear to be growing, maybe this is the best decision. 3. You can change your coding technique to include this new "definition" of How Things Work. Having done this, you can then get on with the business of making money, which I find more interesting than the hobby of Making People Wrong. By the way, #3 is what we did with the Sun 2 compiler bug. When I did a re-port a year later, Sun's in-house porting machine, which was a Sun 3 and which I would expect to be running the Latest and Greatest, still exhibited exactly the same bug. After doing a large number of ports, you will end up with a Working Definition of C/UNIX/whatever that is based on empirical evidence, instead of on the Bible (read SVID, K&R, ANSI C, man pages, etc.). Harris goes on to say: > >A number of the participants in this discussion seem to be of the >opinion that there is no objective standard against which the >correctness of various implementations or opinions about the language >can be judged. This is simply not true. > The existence of an objective standard and the acknowledgement of that standard by way of validated implementations are two entirely different things. The real world is composed mainly of implementations that are "great" if they are a near-miss of some standard. Many systems do not get as close as a near-miss. For example, I know of 6 different implementations of "standard" 4.2 symbols and 12(!) different "standard" implementations of AT&T's Common Object File Format. I know of compilers which don't handle "x = y = z;" correctly, loaders and os ports that don't handle the "-N" flag correctly, and of a couple dozen systems that have "standard" library routines that either don't do what other compnaines are doing OR don't do what their own man pages say. The pragmatic developer dreams of standards, but lives with reality. .... and that's The Truth. ;-)
guy@gorodish.UUCP (04/29/87)
> (See my response to Chris Torek regarding my use of the word "require" > with regard to #define NULL ((char *)0). ) Also note your own article, in which you indicate that you chose a technique for expressing the required casts of null pointers that obviates the need for embedding a cast in the definition of NULL. In fact, you also indicate the reason why you chose this technique was, in fact, that embedding a cast in the definition of NULL is NOT sufficient to solve the problem. In other words, the defensive programming encouraged by an earlier poster requires that you write your code in such a fashion as to make the definition of NULL as anything other than 0 unnecessary. As such, why do people continue to argue that there is some merit to defining NULL as something other than 0? > The existence of an objective standard and the acknowledgement of > that standard by way of validated implementations are two entirely > different things. The real world is composed mainly of implementations > that are "great" if they are a near-miss of some standard. Many systems > do not get as close as a near-miss. However, this in no way justifies the acceptance of blatant errors (such as compiling "if (!charptr)" into something other than a comparison of "charptr" with a null poiner), or indicates that the "real" definition of C requires that such comparisons be written as "if (charptr == (char *)NULL)". We're not talking nits here; we're talking C Programming 101. If some implementor can't get that right, why should I trust them to have gotten anything else right? There is a tradeoff involved here. If an implementation is fundamentally flawed, the cost of trying to find all cases where perfectly legitimate C code could exceed the benefits of making your code work in that implementation. For those of you who came in late, I present the following from the article that kicked this discussion off in the first place: > 4: stupid problems from [censored] programmers who think that > sizeof(int) == sizeof(char *) is a universal constant. similiar > problems from similar programmers who assign pointers of different > types w/o casts. (e.g. char * = char ** w/ no cast). also present > are things like: > charptr = malloc(1024); > if ( !charptr ) ... /* this should be (charptr != (char *)NULL) */ OK. Now it is true that setbuf(stream, NULL); is a case of code written by a programmer who was careless about casting pointers. HOWEVER, what I objected to was lumping the "if (!charptr)" into this category. It is WRONG to censure a programmer for using this construct because it doesn't happen to work on some broken compiler. It is not the responsibility of the developers of netnews (or any other program) to worry about the myriad ways in which somebody can get a C implementation wrong. If you happen to be stuck with a compiler that exhibits this behavior, that's your problem; it is not the responsibility of the authors of netnews to write their code so as to avoid that compiler's problem. Let us take an example of a C implementation with a fairly fundamental flaw. (This implementation really existed, and at one point I had to use it.) This particular implementation provided separate I&D space, and represented a null pointer by an all-zero bit pattern. However, it did not provide a shim at location 0 of the data segment, as is required in order to ensure that a null pointer not refer to any object. The fact that this implementation exists does not mean that C "really" doesn't guarantee that null pointers do not point to an object; it means that the implementation is flawed, and that the user is required to fix the implementation. This particular problem was fairly straightforwardly fixed by linking in an extra module that stuck the shim in. To put it bluntly, programmers have only a finite amount of time to worry about code that doesn't work on a given implementation. I, for one, will devote a lot more effort to fixing incorrect code that doesn't work on a correct implementation that I will devote to "fixing" correct code that doesn't work on an incorrect implementation, and will devote a lot more effort to fixing incorrect implementations on which correct code doesn't work than I will devote to "fixing" correct implementations on which incorrect code doesn't work.
peter@thirdi.UUCP (04/29/87)
In article <17576@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >..... you also indicate the reason why you chose this technique was, >in fact, that embedding a cast in the definition of NULL is NOT >sufficient to solve the problem. > ...... >As such, why do people continue to argue that there is some merit to >defining NULL as something other than 0? You are correct. My point was simply that by having NULL be a (char *)0, it might nail fewer people. It will not save anyone from a truly bizare system. >For those of you who came in late, I present the following .... You are also correct in that I missed the original. > ..... >[I] will devote a lot more effort to fixing incorrect implementations on >which correct code doesn't work than I will devote to "fixing" >correct implementations on which incorrect code doesn't work. Actually, if more people working for machine vendors had this attitude, developers would probably have to spend less time thinking of the most paranoid way to write a piece of code. Unfortunately, there are a number of major corporations producing "UNIX" systems which seem to be indifferent to broken or non-conforming code, incapable of fixing it, or down right proud of their "improvements". Maybe, someday, there will be independently generated "report cards" on how well various systems adhere to various standards. Sort of a Consumer's Reports for C/UNIX/whatever. (Dream, Peter, Dream....)
seaney@uxc.cso.uiuc.edu.UUCP (05/01/87)
/* Written 4:26 pm Apr 28, 1987 by peter@thirdi.UUCP in uxc.cso.uiuc.edu:comp.lang.c */ /* ---------- "Religion vs. Reality (no smiling a" ---------- */ (See my response to Chris Torek regarding my use of the word "require" with regard to #define NULL ((char *)0). ) In article <17498@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >>In article <31@thirdi.UUCP> peter@thirdi.UUCP (Peter Rowell) writes: > .... >> This method has stood us in good stead (except when we have foolishly >> violated it) in porting a source-level debugger to over 70 different >> systems - not all of which were done by followers of the True Faith. > >Umm, err, it's not a matter of "faith", so the use of terms connoting >religion is inappropriate and somewhat irritating here. K&R is quite >clear on this matter; if somebody doesn't "believe in" K&R (or ANSI >C), they're perfectly welcome to implement some language that does >things otherwise, they're just not welcome to call it C. > Lighten up, Guy. You're taking things *way* too seriously. The quip about the "True Faith" is/was aimed at people who seem to feel that all systems/compilers which deviate from their personal concept of "correctness" should be Burned at the Stake. Whether you like it or not, there are an amazing number of products out there that are not perfect (Did Sun fix the compiler bug I reported 2 years ago? What about the ptrace bug that crashed the kernel?). If you are a software developer and you wish to market your software as broadly as possible, sooner or later you will run into *at least* one system that is the result of something less that the Immaculate Port. When you encounter such a system, you can do one of three things: 1. You can request/plead/scream/etc. at/with the machine vendor to fix it. If you wait for this to happen, you probably will be very old when the fix is available. You will almost certainly be "late to market". 2. You can decide that you want nothing to do with these cretins. If the company has a small installed base which doesn't appear to be growing, maybe this is the best decision. 3. You can change your coding technique to include this new "definition" of How Things Work. Having done this, you can then get on with the business of making money, which I find more interesting than the hobby of Making People Wrong. By the way, #3 is what we did with the Sun 2 compiler bug. When I did a re-port a year later, Sun's in-house porting machine, which was a Sun 3 and which I would expect to be running the Latest and Greatest, still exhibited exactly the same bug. After doing a large number of ports, you will end up with a Working Definition of C/UNIX/whatever that is based on empirical evidence, instead of on the Bible (read SVID, K&R, ANSI C, man pages, etc.). Harris goes on to say: > >A number of the participants in this discussion seem to be of the >opinion that there is no objective standard against which the >correctness of various implementations or opinions about the language >can be judged. This is simply not true. > The existence of an objective standard and the acknowledgement of that standard by way of validated implementations are two entirely different things. The real world is composed mainly of implementations that are "great" if they are a near-miss of some standard. Many systems do not get as close as a near-miss. For example, I know of 6 different implementations of "standard" 4.2 symbols and 12(!) different "standard" implementations of AT&T's Common Object File Format. I know of compilers which don't handle "x = y = z;" correctly, loaders and os ports that don't handle the "-N" flag correctly, and of a couple dozen systems that have "standard" library routines that either don't do what other compnaines are doing OR don't do what their own man pages say. The pragmatic developer dreams of standards, but lives with reality. .... and that's The Truth. ;-) /* End of text from uxc.cso.uiuc.edu:comp.lang.c */