From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Macros (was Re: Microsoft C 7.0 Problem)
Date: 27 Sep 92 20:45:28 GMT
Article-I.D.: ima.1992Sep27.204528.21110
Organization: Formerly of Interactive Systems, Cambridge, MA

In article <s40ncdg.jsteele@netcom.com> jsteele@netcom.com (John Steele) writes:
>In <1992Sep25.005947.11458@ima.isc.com> karl@ima.isc.com (Karl Heuer) writes:
>>The appropriate convention is that *object-like* macros should be all-caps,
>>but function-like macros should be lowercase.  There's no reason for the user
>>to know or care whether getchar() is a macro.  (In ANSI C, it may or may not
>>be; it holds no special significance in this regard.)
>
>I disagree.  Macros can have unwanted side effects (either object-like or
>function-like) like getchar(),

I don't think you meant what you wrote -- getchar() has side effects (which is
just another way of saying it isn't a pure function), but no "unwanted" ones;
and in any case the macro's side effects are identical to those of the true
function.  I'll assume you meant "like getchar()" to be inside the parens.

>For example, the common mistake made by new C programmers using the toupper()
>macro define (since it evaluates it's argument twice.

Fixed in ANSI C.  (Btw, I don't let the portability problem bother me; if I
port to an environment where toupper() is broken, I'll import my own
ANSI-compatible version of <ctype.h>.)

In <1992Sep26.050850.20725@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
>It is somewhat reasonable to use lower case for *safe* function-like
>macros -- that is, those which do not read an argument more than once.

Yes, I should have been more explicit.  The original comment was about the
"inconsistency" of K&R preaching uppercase but practicing lowercase; my
observation is that the function-like macros in the ANSI Standard, and
presumably most of those found in K&R, are quite all right in lowercase.
(I believe getc() and putc() [second arg only] are the only ANSI C functions
that have license to evaluate an argument more than once, and I have *never*
encountered a program where this mattered.)

>	#define max(p,q) ((p)>(q)? (p): (q))	/* bad style - should be MAX */

Agreed.

>In addition, if getchar() was known to be a function, then
>	int (*fp)() = getchar;
>would be safe.  In ANSI C this *is* safe, because a getchar() function is
>guaranteed to be provided as well even if there is a getchar() macro, but
>not so in classic C.  This argues weakly that the convention of using upper
>case for *all* macro names is a good one.

A function-like identifier is either all-caps or it isn't; the bandwidth of
that particular channel is one bit.  I consider the information "it's
dangerous to use arguments with side effects here" sufficiently important
to consume that bit.  The information "you can't take the address of this
function in Classic C" is not nearly as critical, since the compiler will
flag the error anyway.  I don't consider it important enough to encode it
lexically at all, and certainly not by using the exact same channel that I
want to use for "unsafe macro" indication.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint