Probably won't help much, since the textual representation
of his macro's expansion is likely to look like
something something_else another_thing
... because the spliced newlines vanish before things like
#define are recognized. The #define directive sees all the
spliced physical lines as one long logical line.
I recall a similar problem with macros that expanded into
complete function definitions. Since the entire definition --
function signature, body, the whole works -- was all on one
very long spliced "line," the debugger couldn't set a breakpoint
on a line inside a macroized function, nor "step to next line,"
nor any of those other helpful things ...
Them's the breaks when you use macros, I guess.
I think that the only logical solution is to make a quick & dirty
preprocessor that does multiline expansion by tokenizing strictly to
whitespace and embedding \t, \n, etc in the tokens.
Here's what I'm doing (functions not yet implemented, only data
structures);
typedef struct {
/* token */
char *str;
/* substitution index:
* 0 = no substitution
* 1 = 1st arg
* n = nth arg
*/
unsigned sub;
} token;
typedef struct {
char *macroname;
size_t nargs;
token *tokens;
size_t ntokens;
} macro;
const char mlpp_declare_begin[] = "/*mlpp_declare_begin";
const char mlpp_declare_end[] = "/*mlpp_declare_end";
const char mlpp_define[] = "/*mlpp_define";
const char mlpp_arg_terminator = "*/";
as a parser, so that this can done in a makefile:
../mlpp foo.c foo.mlpp.c
$(CC) foo.mlpp.c -c -o foo.o $(CFLAGS)
The embedded tabs and newlines make it easier to do debugging because $
(CC) will have useful line numbers.