Take the following very simple C program below. My understanding is that the precompiler is first invoked to expand macros and header files etc.
My understanding was that the precompiler would first include all the code (declarations) from the header file stdio.h in the C file before compilation, therefore making the C file bigger and line numbers different, hence the printf() call would be further down the file.
If that's the case, why, during debugging, the line numbers are still correct?
#include <stdio.h>
int main()
{
printf("Hello world!\n");
}
Yes, the content of the header file(s) are included in the text.
The line numbers are preserved because the pre-processor has a mechanism to specify the line numbers:
These line numbers are used in reporting bugs. Typically, the compiler uses a shorthand notation which it understands — it often omits the word
lineand adds extra information — see GCC Preprocessor output for example.You can see by compiling
Put that in a file; try to compile it; notice that the compiler complains about an unknown type
podon line 1000, even though it is line 2 in the source file.You can run the preprocessor and see the (voluminous) output using the
-Eoption with GCC and most Unix-based C compilers:Note that if I included
<stdio.h>, the output would be much larger (I got 577 lines on one machine — that's less than I expected).You may also be able to run a standalone C preprocessor — typically called
cpp— with a subset of the arguments for the C compiler. That will sometimes give you slightly different results from the main compiler, but it is often a good way to see what's going on.Right now, I've got a problem with some code — my test case is:
The compilation error that's distressing me is:
It ain't obvious where there's a string of 4587 characters, until you use
gcc -E:Ouch! I don't know that I'd recognized the assertion if it fired — it doesn't look like the text in the source code, that's for sure! (That's from GCC 9.2.0 running on an ancient RHEL 5 Linux.)