#defines with parameters

[Doug Gwyn]

In article <264 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>In article <1988Nov22.170953.24489 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>    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...

It would be nice if you checked what X3J11 had done before venturing an
opinion.  In the dpANS, unsigned and int are definitely different types,
as they always have been in C.

If you're referring to the adoption of "value preserving" rules for type
conversion, that is clearly a logical improvement over "sign preserving"
rules, leading to surprising behavior less often, and turned out upon
investigation to not break a significant amount of code already written
according to sign-preserving rules.  Both variations were found in
existing practice before X3J11 had to make a choice, and they chose the
patently better set of rules.

char never has been a "range/length" modifier in C, and X3J11 hasn't
tried to change that.  short and long have always produced different
types, not different versions of the same type, and X3J11 hasn't tried
to change that, either.

>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 ?

Yes, the ( introducing the parameters in the definition of a function-
like macro must not be preceded by white space.  Both the May draft and
the current dpANS denote this special ( by the syntactic category
"lparen", which it defines correctly.  Henry was mistaken about this.