Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!garcon!uicsrd.csrd.uiuc.edu!mcdaniel
From: mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel)
Newsgroups: comp.lang.c
Subject: Re: A not so nice macro (was: A nice macro)
Message-ID: <1357@garcon.cso.uiuc.edu>
Date: 23 Jun 89 19:56:52 GMT
References: <2784@solo8.cs.vu.nl> <1330@garcon.cso.uiuc.edu> <2792@solo8.cs.vu.nl>
Reply-To: mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel)
Organization: Center for Supercomputing R&D (Cedar), U. of Ill.
Lines: 75
Keywords:

Karl Heuer, "The Walking Lint", replied via e-mail to my reply to
Maarten.  He gave me permission to post his mail here.  My comments
follow.

----------------------------------------------------------------------

From: karl@ima.UUCP (Karl Heuer)
Subject: Re: A nice macro
Newsgroups: comp.lang.c
In-Reply-To: <1330@garcon.cso.uiuc.edu>
References: <2784@solo8.cs.vu.nl>
Organization: Interactive Systems, Boston

In article <1330@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu
wrote:
>It might be disconcerting, as you [Maarten] note, to see
>        zork(5) = 20;
>in a C program.

Actually, I think "lmacros" are a pretty neat hack; they often are
cleaner than their "standard" counterparts.  (One that I've had
occasion to use is "push(stk)=val", with symmetry to "val=pop(stk)".)
They do take some getting used to.

>Objection 1: in pANS C, many identifiers starting with "_" are
>reserved for the implementation.  Unfortunately, I don't have the
>rules handy, so I can't tell the circumstances under which this
>declaration would be legal.  If "_foo" is extern, I'm pretty sure it
>is illegal.  "real_foo" would be a better choice.

Give the pANS rules for macro expansion, you could use "foo" for both.
This solves the namespace problem, but creates a debugging nightmare.

>>	#define		foo_addr(n)	&foo[(n) - LOW]
>
>might have a similar problem.  "a[b]" was defined by K&R to be
>identical to "*(a+b)", so

Well, if you want to do it as a lexical replacement, it's "*(a+(b))"
(otherwise a[1<<1] would yield *(a+1<<1) which is illegal).  In fact
this is how it's stated in the pANS.

>        &foo[(n) - LOW] <==> (foo + (n) - LOW)
>I don't know whether pANS C specifies the same identity,# or what it
>says about evaluating expressions without parentheses.  If compilers
>are allowed to rearrange, a compiler might instead compute
>         (foo - LOW + (n))

Without the parens, "a+b+c" must be equivalent to "(a+b)+c" because of
the associativity rules.  But in view of the correct identity, we
actually have "(foo + ((n)-LOW))", which is guaranteed to do the right
thing.  So there's no problem here.

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

----------------------------------------------------------------------

So it appears that I neglected my own rule of thumb!  (The one that
says "If you think Chris Torek was wrong, think again".)  It seems
that foo_addr is OK as it stands.

BTW, I personally don't mind lmacros.  However, that goes into a style
issue: how much can you alter the syntactic appearance of C code
before it becomes unreadable?  The original source for the Bourne
shell is a notorious example of Obfuscated C.  Whether or not lmacros
are unbearable is a matter of personal style.  Questions of
programming style are very good generators of flame wars.
--
"Let me control a planet's oxygen supply, and I don't care who makes
the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux)
 __
   \         Tim, the Bizarre and Oddly-Dressed Enchanter
    \               mcdaniel@uicsrd.csrd.uiuc.edu
    /\       mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet}
  _/  \_     {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel