ANSI C and the C Pre-Processor

Joe Mueller joemu at tekecs.UUCP
Fri Sep 28 03:23:12 AEST 1984

> As for what should be done to bring back the lost functionality...  the
> ANSI C folks have basically said "if you want a general-purpose macro
> processor, use m4".  The programs that this "change" will break are
> broken already, and should be fixed to do it right.

As Henry stated, the X3J11 committee (ANSI C), felt that the preprocessor
was not intended to be a general purpose macro processor, BUT, we did
acknowledge that there was a large body of code that used these types
of "features". The committee is currently concidering proposals for

a) token concatination operations within the preprocessor. It will
   definitely NOT be startoftoken/**/argument. Currently it looks like
   the # will be used like this: startoftoken#argument. I don't believe
   we have definitely decided the syntax for the operation. I think that
   the committee did decide that the functionality was needed.

b) "stringizing" (I didn't make up this term, someone else did) arguments
   is also under concideration. One proposal is to do the substitution
   if the argument name is the only thing within the quotes. i.e.
   #define foo(bar) printf("bar")
   will expand bar within the quotes where
   #define foo(bar) printf("the argument was bar")
   will not expand bar.

The committee is not as dogmatic as it sounds on the net. It is our
intention to produce a standard that will allow someone to do
serious work without resorting to non-portable extensions.

Please continue to discuss concerns about the developing standard
on the net. I know several committe members (including myself) read
it regularly.

If you have alternate proposals for the machinery to do the above
operations, let me know.

More information about the Comp.lang.c mailing list