https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The question of what value a __LINE__ macro should expand in the invocation of
a function-like macro that spans multiple lines was discussed by the C
committee in February 2015. The consensus in the discussion was that:
1) the __LINE__ macro expands to the physical source line number (as opposed to
logical line number)
2) the logical line number is one greater than the number of new-line
characters read or introduced in translation phase 1 while processing the
source file to the current token
3) __LINE__ (along with all other) tokens only come into existence in phase 3
of translation
4) in an invocation of a function-like macro, any new-line characters must be
read to form the logical line containing the invocation (including its
arguments)
Thus, all __LINE__ tokens that are formed as a result of the expansion of a
function-like macro must expand to the number of the physical line that
contains the closing parenthesis the macro invocation.
According to this interpretation the following test is expected to pass (and
does with gcc 4.9 and 5):
#define F(x, y, z) a = __LINE__, b = x ## y, c = z
enum {
#line 10
F
(
__LI,
NE__,
__LINE__
)
};
#define A(e) _Static_assert (e, #e)
A (a == 15);
A (b == 15);
A (c == 15);
During the committee discussion it was observed that not all implementations
get this right. A paper has been submitted into the Spring 2015 mailing to
reflect this issue (below). The paper will be discussed at the April 2015
meeting in Lysaker.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1911.htm
