Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!amdahl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.lang.c Subject: Re: Writing readable code Message-ID: <837@mcgill-vision.UUCP> Date: Sat, 11-Jul-87 05:21:22 EDT Article-I.D.: mcgill-v.837 Posted: Sat Jul 11 05:21:22 1987 Date-Received: Sat, 18-Jul-87 19:09:17 EDT References: <13008@topaz.rutgers.edu> <1941@zeus.TEK.COM> <849@tjalk.cs.vu.nl> Organization: McGill University, Montreal Lines: 62 Keywords: Who's obfuscated? In article <849@tjalk.cs.vu.nl>, rblieva@cs.vu.nl (Roemer b Lievaart) writes: >>> if( bool == TRUE ) >>> [which] is different than >>> if(!bool) > Of course it's different. If bool can only be 0 or TRUE, If it were possible to guarantee somehow that bool could take on only the values 0 and TRUE, we'd be nearly home. Unfortunately, one-bit unsigned bitfields are ugly to declare (must be structure members), uncommon, and usually inefficient. Therefore, we are, generally, stuck with using types that can take on more than two values. > To avoid some misunderstandings: > isdigit(), isalpha(), etc. > do NOT just return FALSE or "TRUE" (1)!!! > if ( isalpha('a') ) puts("yes") ; else puts("no") ; > if ( isalpha('a') == TRUE ) puts("yes") ; else puts("no") ; [prints] > yes > no > Do you get it? isalpha('a') is not true! $%?! > It's not true, it's 2. isalpha('a') *is* true. It is not TRUE. True, in C, is defined to be non-zero. 2, therefore, is true. That's why the first if worked correctly, or should I say unsurprisingly. > However, I must say I'm very against using '0' instead of NULL. > [clarity of intended type argument] I agree in principle. Unfortunately, I disagree in practice. My reasons are strictly pragmatic: (a) too many C implementations have NULL defined as something wrong (ie, other than plain unadorned 0), (b) using 0 doesn't mean I have to include some .h file, and (c) using 0 makes it plain to someone trying to debug the code and/or a port of it that the problem is *not* a mis-defined NULL. > Our lint complains about: > main() { bar(NULL); } > bar(foo) char *foo; {...} > [Lint's complaint should be]. Instead lint says: > "bar, arg. 1 used inconsistently ..." > Which is not true. I didn't use the argument inconsistently, I > passed a NULL-pointer which is a correct pointer. No you didn't, you passed the integer zero (assuming a correct definition of NULL), which is no sort of pointer at all. Lint is perfectly correct. > char *strings[] = { "one", "two", "three", NULL } ; > This won't pass our compiler. Then either your compiler or the definition of NULL that you're getting is broken, I would say. (No definitive reference comes to mind; anybody care to produce one?) der Mouse (mouse@mcgill-vision.uucp)