Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!sun!amdahl!netcom!ergo From: ergo@netcom.UUCP (Isaac Rabinovitch) Newsgroups: comp.lang.c Subject: Re: NULL as a string terminator Message-ID: <12249@netcom.UUCP> Date: 20 Aug 90 15:38:50 GMT References: <24141@megaron.cs.arizona.edu> <134@blekko.UUCP> <1990Aug20.000227.12867@icc.com> <1990Aug20.073554.9537@zoo.toronto.edu> Reply-To: ergo@netcom.uucp Organization: UESPA Lines: 50 In <1990Aug20.073554.9537@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >>>In many cases the object itself becomes familiar enough that it's >>>instantly recognized. '\0' is one such object. If I saw in your >>>code >>> >>> *p = EOS; >>> >>>I'd have to run off to your .h files to find the definition of EOS. >> >> Perhaps a comment in an appropriate place might alleviate this. >Comments are not a substitute for using familiar practices instead of >unfamiliar ones. Familiar ones should be preferred unless there is >a *substantial* advantage to be had. I don't see one here. I agree with you in principle, and also in this instance (does anyone seriously intend to put a comment at every end-of-string comparison?). The problem is with the concept of "familiar". This business of strings always terminating with a null is fundamental to C programming -- if you don't know that '\0' means "end-of-string" then you simply don't know how C strings work at all! (Note that nobody ever uses an (int) 0 in place of '\0', even though the two are equivalent!) On the other hand, you can say (and I used to) that using 1 and 0 instead of TRUE and FALSE is a similar "familiar practice", since any competant C programmer knows that C booleans are just integers. In this case it probably makes a big difference that TRUE and FALSE are ordinary English words, not obscure acronyms. I recently came up against a similar clash of "familiar concepts" in C. People were arguing (was it in this group?) over why programmers use "i" instead of "i == 0". I asserted that this shorter expression usually generated tighter code, at least on stupider compilers. I think I might have been right about this 10 years ago, but even if I was I'd only shown I was out of date in the current state of compiler writing. I got one private message from a guy at a certain Big Software Company who told me that reducing such comparisons was the first optimization any compiler writer implemented. True enough, but what I found especially interesting was all the public and private flames fired at me by folks who insisted not just that I was wrong (which, of course, I was) but that the C language was *defined* to include such a reduction! -- ergo@netcom.uucp Isaac Rabinovitch atina!pyramid!apple!netcom!ergo Silicon Valley, CA uunet!mimsy!ames!claris!netcom!ergo Disclaimer: I am what I am, and that's all what I am!