#defines with parameters [was :Re: v05i053: A "safe" ... ]

Piercarlo Grandi pcg at aber-cs.UUCP
Fri Nov 25 00:24:00 AEST 1988


In article <1988Nov22.170953.24489 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:

    In article <122 at halcdc.UUCP> randy at halcdc.UUCP (randy orrison) writes:
    >|>Two problems: the space after gets would kill it if it's a macro,
    >|
    >|Say WHAT?  Works fine on all the compilers I know of.  "Preprocessor"
    >|macros don't require that you give the exact same amount of white space
    >|in the invocation as you gave in the definition...
    
    Definitions of parameterized macros ("function-like" macros in
    X3J11speak) have always been required to have the "(" immediately
    following the identifier.  The May draft standard requires that in
    the invocation, the "(" must be "the next preprocessor token",
    which basically means that white space there is okay.

Now I have always had a low opinion of the X3J11 work (e.g. not to
realize that unsigned and int are different types, as they obey
different rules for arithmetic, and char short and long are just
range/length modifiers, and not the other way round), but this last
idea really leaves me gasping...

Obviously there must me a way to distinguish between macro bodies that
begin with a "(" and macro definitions with a parameter list, is there
one ?

I mean one that is not a trick like defining a null token BODY or putting
a null comment before the "(" that starts the body, and one that does not
break all the existing macro definitions that whether with parameters
or not you had better enclose in parenthesis...
-- 
Piercarlo "Peter" Grandi			INET: pcg at cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)



More information about the Comp.lang.c mailing list