Etydhv

Why does __LINE__ evaluate differently based on whether it's used inside a function-like macro or a regular function?

For example:

#include<stdio.h>

#define A() printf("%dn",__LINE__);

int main(void) 
/* 6 */ A();
/* 7 */ A(
/* 8 */ );
/* 9 */ printf("%dn",__LINE__
/* 10 */ );

I would expect to get:

6
7
9

But instead we get:

6
8
9

Note how in the function-like macro spread over lines 7 & 8, the last line occupied is used, rather than the first.

GCC's documentation is light on details: https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html

Why do I care? I'm writing a parser that needs to find the line numbers of all instances of the macro A in such a way as to line up with what __LINE__ will return. It is much harder to find the last line of the macro usage rather than the first due to the need to parse possibly escaped arguments.

The C implementation does not replace the A() macro until it sees the closing ). That ) appears on line 8, so that is the point at which macro replacement occurs.

The specifics of __LINE__ with regard to macro replacement are not well specified by the C standard. You should likely not rely on a particular behavior here. Certainly the C implementation cannot replace the A() macro while it has read only up to line 7, as it does not know what is coming yet. Once it has seen the closing ), then, as it replaces the macro, it might consider the replacement tokens to be occurring on line 7 or on line 8 or on some mix—the C standard is not specific about this; line numbers are largely irrelevant to C semantics at this point, and the __LINE__ macro is largely a convenience for debugging and other development work, not a feature for production programs (although it may have some uses for them).

In the printf, the C implementation recognizes the __LINE__ macro as soon as it sees the end of the line. (Actually, the parsing is more involved; the input has been tokenized, but the effect is the __LINE__ token is recognized when the end-of-line character is examined.) It is on line 9, so it is replaced by 9. The fact it is an argument to printf is irrelevant. The C implementation does not have the process the printf in order to replace the __LINE__ token that appears on line 9; they do not interact.