__LINE__Authors: Jay Ghiron
Date: 2026-03-05
Submitted against: C23
Status: Open
Cross-references: 0464, 1016
Issue 1016 was resolved as not allowing digit separators
in __LINE__. However, there are other issues with the permissible
spellings of __LINE__. Specifically relating to #line __LINE__ as
mentioned in DR 464. First, if __LINE__ expands to a
binary constant or a hexadecimal constant then #line __LINE__ is
invalid. Second, if __LINE__ expands to include an integer suffix
then #line __LINE__ is also invalid. Third, if __LINE__ expands
to an octal constant then #line __LINE__ will possibly result in a
different value. For example:
//line 1
//line 2
//line 3
//line 4
//line 5
//line 6
//line 7
#line __LINE__
__LINE__
As indicated in DR 464, this could expand to eight or
nine. However if an octal constant were used, this could instead
expand to ten or eleven. Since #line 010 is interpreted as setting
the line number to ten, not eight.
Is it intended that #line __LINE__ must be valid?
Is it intended that #line __LINE__ cannot have more than two
possible results due to octal constants possibly being used?
Outside of #line __LINE__, should the spelling of __LINE__ be
strictly defined so that stringization and concatenation have well
defined results? For example:
#define CAT(X,Y,...)__VA_OPT__(X)##__VA_OPT__(Y)
#define DEFINE int CAT(v,__LINE__,,);CAT(v,__LINE__,,)=42
int main(){
DEFINE;
}
There are many programs like this that rely on the spelling of
__LINE__ being consistent within a line. See also C++ CWG
3142.
Comment from Issues list maintainer on 2026-08-21:
At the August 2026 (Ottawa) meeting of WG14, it was agreed that
__LINE__ should be decimal or possibly 0 so that #line __LINE__
works and there is a unique possible spelling for a given line number.
Joseph Myers took an action item to propose wording for this,
preferably similar to the wording used in C++.
Comment from Issues list maintainer on 2026-08-25:
In reflector message 37710, Joseph Myers proposed wording for this issue.
The following proposed wording is based on C2y draft N3886; for C23 (as amended by issue 1016), "integer literal" and "decimal literal" should be read as "integer constant" and "decimal constant".
Change 6.10.10.2 Mandatory macros:
__LINE__Thepresumed line number (within the current source file) of the current source line (aninteger literal0or an unsuffixed decimal literal (6.4.5.2), excluding any digit separators), representing the presumed line number of the current source line within the current source file.