Otherwise, we get those pesky warnings when doing so: $ cat hello.c #include <stdio.h> int main(void) { puts("Hello world"); } $ c99 -E hello.c >hello_.c $ c99 hello_.c hello_.c:1:3: warning: style of line directive is a GCC extension 1 | # 0 "hello.c" | ^ hello.c: warning: style of line directive is a GCC extension <built-in>: warning: style of line directive is a GCC extension <command-line>: warning: style of line directive is a GCC extension <command-line>: warning: style of line directive is a GCC extension hello.c:1:3: warning: style of line directive is a GCC extension 1 | #include <stdio.h> | ^ hello.c:4:3: warning: style of line directive is a GCC extension 4 | { | ^
(In reply to Hadrien Lacour from comment #0) > $ c99 -E hello.c >hello_.c > $ c99 hello_.c Why would you do that? This seems like a contrived example. Do you have a real example of a build system that pre-processes its source files explicitly before compiling them?
My own build system, where in at least one case, I add my own preprocessing that I still want to interact "as expected" with #if and friends (https://git.sr.ht/~q3cpma/posix-build/tree/master/item/build_util.sh#L1345 for reference). What's the argument against, anyway? -E is specified by POSIX, and without -P, gcc produces non standard C (unless unknown directives are specified as ignored, I don't know).
I suspect losing the line markers would make for less results when debugging. I'm not sure what else (if anything) it would break.
s/less/less useful/
That said, I would guess that very few people actually use the "c99" command, so changing its behavior will have limited impact.
Personally, I think that since the wrapper is just here to satisfy POSIX, conformance should be the first goal.
