Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!decvax!cca!ima!haddock!dan
From: dan@haddock.UUCP
Newsgroups: net.lang.c
Subject: Re: preprocessor question - (nf)
Message-ID: <139@haddock.UUCP>
Date: Sun, 25-Mar-84 23:37:07 EST
Article-I.D.: haddock.139
Posted: Sun Mar 25 23:37:07 1984
Date-Received: Tue, 27-Mar-84 01:05:49 EST
Lines: 27

#R:ccieng5:-30100:haddock:12400005:000:1125
haddock!dan    Mar 24 18:15:00 1984

It can't be done.  Not easily, anyway.  The only reason it doesn't work is
that after the macro is expanded, there's no newline before the # to signal
the preprocessor that this is another control to process.  You could modify
the preprocessor so that the sequence \<newline>, instead of being completely
dropped, turns into a <newline> in the macro definition (I know, I did it
once).  But I don't recommend it.  Instead, you might try writing the macro
with an embedded special character like '@' where newlines ought to appear,
running the source through cpp alone to expand the definitions, and then
running the result through 'tr' to convert those characters to newlines.
Then run the result through the preprocessor again (and the rest of the
compiler).  Example:

#define foo(x) \
@#if x \
@some code \
@#endif

might be the source.  The commands would be something like

cc -P foo.c; tr '@' '\012' <foo.i >x.c; cc x.c

I used -P because it will preserve line number information.  Nonetheless,
the line numbers in diagnostics (and debuggers) should be regarded with
healthy skepticism the first few times you do this.