One more point regarding = and == (more flamage)

[Adam S. Denton]

In article <1991Mar27.184833.7914 at sq.sq.com> dak at sq.sq.com (David A Keldsen) writes:
>
>>In article <13603 at helios.TAMU.EDU> byron at archone.tamu.edu (Byron Rakitzis) writes:
>>Yes.  Deliberately using a construct that looks like a well-known and subtle
>>programming error is a mistake.  Your successor, reading your code, should
>>*never* have to ask himself "is this really right?"; if there is reason for
>>doubt, either comment the code or change it.
>
>I agree with the principle, but I disagree that it applies here.  The 
>programmer must balance clarity-by-standard-idiom and clarity-by-explicitness.
>
>From K&R1 (p. 101):
>        ...
>        while (*s++ = *t++)
>        ...
>
>"Although this may seem cryptic at first sight, the notational convenience
>is considerable, and the idiom should be mastered, if for no other reason
>than that you will see it frequently in C programs."
>
>I find the idiomatic usage to be clearer, because it is easier to recognize.

Although K&R was the original, and the 2nd edition is exemplary, there
are two areas in the original that I have come to disagree with
(and I think others in this forum have too):

  1) The construct you cite above, and
  2) The `hint' that pointers have anything AT ALL to do with integers

I disagree with K&R on both these points.   "while (a++ = b++)" might
be cute, but it is truly annoying to have to sift through the code
to determine if it's a bug or not.  Especially since the != 0 test
could just have easily been included, effectively removing all ambiguity
and with no run-time penalty (as others have pointed out) and with no howl
from lint as an added bonus.

The second construct is dealt with in the FAQ, but I still see this misuse
in even "modern" code -- consider the following code, which is ubiquitous
in MSDOS: (my apologies for including platform-specific code here)

   void far *p;
   ...
   p = (void far *) 0xFFFFE000;

when IMHO the proper abstraction should be

   void far *p;
   ...
   p = MK_FP(0xFFFFu, 0xE000u);

as the latter does not include an integer-to-pointer conversion, and I would
hold that it is more portable (most MSDOS compilers include the MK_FP macro
FOR PRECISELY the purpose of avoiding an integer-to-pointer conversion).

This topic touches on issues of proper data abstraction and typing which are
not discussed sufficiently in most C books.  That may be why there is such
a debate, and why code like the former above continues to be written.

Happy coding,

Adam Denton
asd at mtqua.att.com