Behavior of __LINE__ when used in a macroWhy use apparently meaningless do-while and if-else statements in macros?Why are these constructs using pre and post-increment undefined behavior?#define macro for debug printing in C?Undefined, unspecified and implementation-defined behaviorHow to redefine a macro using its previous definitionDocumentation concerning platform-specific macros in Linux/POSIXWhy is my program slow when looping over exactly 8192 elements?Can code that is valid in both C and C++ produce different behavior when compiled in each language?Writing a variadic macro which sets specific bits in an integer (bit-mask)Is there a tool that checks what predefined macros a C file depends on?
How do you cope with rejection?
Can the word crowd refer to just 10 people?
Would it be possible to set up a franchise in the ancient world?
Does a windmilling propeller create more drag than a stopped propeller in an engine out scenario?
Precedent for disabled Kings
Can 2 light bulbs of 120V in series be used on 230V AC?
Is it a good idea to teach algorithm courses using pseudocode instead of a real programming language?
Is a reptile with diamond scales possible?
Why did Nick Fury not hesitate in blowing up the plane he thought was carrying a nuke?
Is it appropriate to ask a professor to bump up a grade when I suspect it may be at the cutoff?
Why is python script running in background consuming 100 % CPU?
How could Dwarves prevent sand from filling up their settlements
Why could the Lunar Ascent Engine be used only once?
Why does the U.S military use mercenaries?
How can I prevent Bash expansion from passing files starting with "-" as argument?
Bash - Execute two commands and get exit status 1 if first fails
Isn't Kirchhoff's junction law a violation of conservation of charge?
Can I have a delimited macro with a literal # in the parameter text?
In how many ways can we partition a set into smaller subsets so the sum of the numbers in each subset is equal?
Why didn't Daenerys' advisers suggest assassinating Cersei?
Very serious stuff - Salesforce bug enabled "Modify All"
Warped chessboard
Reference for electronegativities of different metal oxidation states
Why can I not put the limit inside the limit definition of e?
Behavior of __LINE__ when used in a macro
Why use apparently meaningless do-while and if-else statements in macros?Why are these constructs using pre and post-increment undefined behavior?#define macro for debug printing in C?Undefined, unspecified and implementation-defined behaviorHow to redefine a macro using its previous definitionDocumentation concerning platform-specific macros in Linux/POSIXWhy is my program slow when looping over exactly 8192 elements?Can code that is valid in both C and C++ produce different behavior when compiled in each language?Writing a variadic macro which sets specific bits in an integer (bit-mask)Is there a tool that checks what predefined macros a C file depends on?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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 (using clang-1000.10.44.4):
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.
c gcc c-preprocessor
asked 6 hours ago
Chris MerckChris Merck
19510
add a comment |
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 (using clang-1000.10.44.4):
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.
c gcc c-preprocessor
asked 6 hours ago
Chris MerckChris Merck
19510
1
Ultimately you will need to do the parsing correctly anyway, as there may be macros within macro arguments and other complications.
– Eric Postpischil
6 hours ago
1
I am suprised to see, that the output changed with last gcc version. So: no worries. When you update to gcc9.1 the output will match expected(!), see godbolt. I am also suprised to see there is no double;;on the end of the second line inmainwhen usinggcc -E.
– Kamil Cuk
6 hours ago
@Kamil: The missing;is a gift from godbolt. If you disable the filtering of "comment-only lines" (the//button), you'll see the semicolons on both gcc versions.
– rici
59 mins ago
@KamilCuk #1 godbolt is AWESOME, #2 I'm terrified that this behavior changes in gcc 9. That's enough evidence to make me reconsider my approach to logging.
– Chris Merck
55 mins ago
add a comment |
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 (using clang-1000.10.44.4):
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.
c gcc c-preprocessor
asked 6 hours ago
Chris MerckChris Merck
19510
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 (using clang-1000.10.44.4):
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.
c gcc c-preprocessor
c gcc c-preprocessor
asked 6 hours ago
Chris MerckChris Merck
19510
asked 6 hours ago
Chris MerckChris Merck
19510
edited 40 mins ago
Chris Merck
asked 6 hours ago
Chris MerckChris Merck
19510
asked 6 hours ago
Chris MerckChris Merck
19510
asked 6 hours ago
Chris MerckChris Merck
19510
19510
1
Ultimately you will need to do the parsing correctly anyway, as there may be macros within macro arguments and other complications.
– Eric Postpischil
6 hours ago
1
I am suprised to see, that the output changed with last gcc version. So: no worries. When you update to gcc9.1 the output will match expected(!), see godbolt. I am also suprised to see there is no double;;on the end of the second line inmainwhen usinggcc -E.
– Kamil Cuk
6 hours ago
@Kamil: The missing;is a gift from godbolt. If you disable the filtering of "comment-only lines" (the//button), you'll see the semicolons on both gcc versions.
– rici
59 mins ago
@KamilCuk #1 godbolt is AWESOME, #2 I'm terrified that this behavior changes in gcc 9. That's enough evidence to make me reconsider my approach to logging.
– Chris Merck
55 mins ago
add a comment |
1
Ultimately you will need to do the parsing correctly anyway, as there may be macros within macro arguments and other complications.
– Eric Postpischil
6 hours ago
1
I am suprised to see, that the output changed with last gcc version. So: no worries. When you update to gcc9.1 the output will match expected(!), see godbolt. I am also suprised to see there is no double;;on the end of the second line inmainwhen usinggcc -E.
– Kamil Cuk
6 hours ago
@Kamil: The missing;is a gift from godbolt. If you disable the filtering of "comment-only lines" (the//button), you'll see the semicolons on both gcc versions.
– rici
59 mins ago
@KamilCuk #1 godbolt is AWESOME, #2 I'm terrified that this behavior changes in gcc 9. That's enough evidence to make me reconsider my approach to logging.
– Chris Merck
55 mins ago
1
1
Ultimately you will need to do the parsing correctly anyway, as there may be macros within macro arguments and other complications.
– Eric Postpischil
6 hours ago
Ultimately you will need to do the parsing correctly anyway, as there may be macros within macro arguments and other complications.
– Eric Postpischil
6 hours ago
1
1
I am suprised to see, that the output changed with last gcc version. So: no worries. When you update to gcc9.1 the output will match expected(!), see godbolt. I am also suprised to see there is no double
;; on the end of the second line in main when using gcc -E.– Kamil Cuk
6 hours ago
I am suprised to see, that the output changed with last gcc version. So: no worries. When you update to gcc9.1 the output will match expected(!), see godbolt. I am also suprised to see there is no double
;; on the end of the second line in main when using gcc -E.– Kamil Cuk
6 hours ago
@Kamil: The missing
; is a gift from godbolt. If you disable the filtering of "comment-only lines" (the // button), you'll see the semicolons on both gcc versions.– rici
59 mins ago
@Kamil: The missing
; is a gift from godbolt. If you disable the filtering of "comment-only lines" (the // button), you'll see the semicolons on both gcc versions.– rici
59 mins ago
@KamilCuk #1 godbolt is AWESOME, #2 I'm terrified that this behavior changes in gcc 9. That's enough evidence to make me reconsider my approach to logging.
– Chris Merck
55 mins ago
@KamilCuk #1 godbolt is AWESOME, #2 I'm terrified that this behavior changes in gcc 9. That's enough evidence to make me reconsider my approach to logging.
– Chris Merck
55 mins ago
add a comment |
1 Answer
1
active
oldest
votes
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.
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
2
The first point here is important, but the second is crucial. The standard provides no basis for judging the observed behavior either more or less correct than the OP's expected behavior.
– John Bollinger
6 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f56193082%2fbehavior-of-line-when-used-in-a-macro%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
2
The first point here is important, but the second is crucial. The standard provides no basis for judging the observed behavior either more or less correct than the OP's expected behavior.
– John Bollinger
6 hours ago
add a comment |
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.
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
2
The first point here is important, but the second is crucial. The standard provides no basis for judging the observed behavior either more or less correct than the OP's expected behavior.
– John Bollinger
6 hours ago
add a comment |
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.
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
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.
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
edited 6 hours ago
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
answered 6 hours ago
Eric PostpischilEric Postpischil
83.2k890169
83.2k890169
2
The first point here is important, but the second is crucial. The standard provides no basis for judging the observed behavior either more or less correct than the OP's expected behavior.
– John Bollinger
6 hours ago
add a comment |
2
The first point here is important, but the second is crucial. The standard provides no basis for judging the observed behavior either more or less correct than the OP's expected behavior.
– John Bollinger
6 hours ago
2
2
The first point here is important, but the second is crucial. The standard provides no basis for judging the observed behavior either more or less correct than the OP's expected behavior.
– John Bollinger
6 hours ago
The first point here is important, but the second is crucial. The standard provides no basis for judging the observed behavior either more or less correct than the OP's expected behavior.
– John Bollinger
6 hours ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f56193082%2fbehavior-of-line-when-used-in-a-macro%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Ultimately you will need to do the parsing correctly anyway, as there may be macros within macro arguments and other complications.
– Eric Postpischil
6 hours ago
1
I am suprised to see, that the output changed with last gcc version. So: no worries. When you update to gcc9.1 the output will match expected(!), see godbolt. I am also suprised to see there is no double
;;on the end of the second line inmainwhen usinggcc -E.– Kamil Cuk
6 hours ago
@Kamil: The missing
;is a gift from godbolt. If you disable the filtering of "comment-only lines" (the//button), you'll see the semicolons on both gcc versions.– rici
59 mins ago
@KamilCuk #1 godbolt is AWESOME, #2 I'm terrified that this behavior changes in gcc 9. That's enough evidence to make me reconsider my approach to logging.
– Chris Merck
55 mins ago