Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

77%
+5 −0
Q&A What is do { } while(0) in macros and should we use it?

Reasons to use the construct #define FOO(x) do{...} while(0);: As mentioned above, doing so solves the problem of if (...) FOO(y); You can declare variables inside the block, and they ...

posted 3y ago by Pete W‭  ·  edited 4mo ago by Karl Knechtel‭

Answer
#9: Post edited by user avatar Karl Knechtel‭ · 2023-11-21T14:31:42Z (4 months ago)
Use code formatting for code and list formatting for the list; fix some minor grammar etc. issues
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you can to declare variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared elsewhere in the block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes FOO(func(y)), where func has side effects. This includes FOO(y++) etc. After the macro expands, the side effect would happen as many times as the macro argument appears in the body!
  • Declaring a variable inside a do {} block prevents this, as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
  • Reasons to use the construct `#define FOO(x) do{...} while(0);`:
  • 1. As mentioned above, doing so solves the problem of
  • ```
  • if (...) FOO(y);
  • ```
  • 1. You can declare variables inside the block, and they harmlessly go out of scope at the end of the block. Without the `do{}` block, the same symbol would cause a warning (or worse) if it were declared elsewhere in the block in which `FOO(x)` gets expanded.
  • Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes `FOO(func(y))`, where `func` has side effects. This includes `FOO(y++)` etc. After the macro expands, the side effect would happen as many times as the macro argument appears in the body!
  • Declaring a variable inside a do {} block prevents this, as follows:
  • ```
  • #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • ```
  • Obviously there is still an assumption about type of `x`, but that is the case anyway if you are going to be calling `func2(x)` etc.
  • 1. Without the `do{}` block, there might be ambiguity as to whether `FOO(x)` expands into a statement or an expression. `do{}` makes it clearly a statement, which can help catch someone trying to use `FOO(x)` where an expression is expected. See also: "statement-expressions", aka `({...})`, which is a construct in case you want the block to be an expression rather than a statement.
#8: Post edited by user avatar Pete W‭ · 2020-12-17T15:42:17Z (over 3 years ago)
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you can to declare variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared elsewhere in the block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes FOO(func(y)), where func has side effects. This includes FOO(y++) etc. After the macro expands, the side effect would happening multiple times.
  • Declaring a variable inside a do {} block prevents this, as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you can to declare variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared elsewhere in the block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes FOO(func(y)), where func has side effects. This includes FOO(y++) etc. After the macro expands, the side effect would happen as many times as the macro argument appears in the body!
  • Declaring a variable inside a do {} block prevents this, as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
#7: Post edited by user avatar Pete W‭ · 2020-12-17T15:40:51Z (over 3 years ago)
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes FOO(func(y)), where func has side effects. This includes FOO(y++) etc. After the macro expands, the side effect would happening multiple times.
  • Declaring a variable inside a do {} block prevents this, as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you can to declare variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared elsewhere in the block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes FOO(func(y)), where func has side effects. This includes FOO(y++) etc. After the macro expands, the side effect would happening multiple times.
  • Declaring a variable inside a do {} block prevents this, as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
#6: Post edited by user avatar Pete W‭ · 2020-12-17T15:39:53Z (over 3 years ago)
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case someone writes FOO(y++). Or more generally FOO(func(y)) , where func has side effects.
  • The do {} block is then used as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case a macro argument appears more than once in the body, and someone writes FOO(func(y)), where func has side effects. This includes FOO(y++) etc. After the macro expands, the side effect would happening multiple times.
  • Declaring a variable inside a do {} block prevents this, as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
#5: Post edited by user avatar Pete W‭ · 2020-12-17T15:36:54Z (over 3 years ago)
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(x);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case someone writes FOO(y++). Or more generally FOO(func(y)) , where func has side effects.
  • The do {} block is then used as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(y);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case someone writes FOO(y++). Or more generally FOO(func(y)) , where func has side effects.
  • The do {} block is then used as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
#4: Post edited by user avatar Pete W‭ · 2020-12-17T15:36:25Z (over 3 years ago)
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(x);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case someone writes FOO(y++). Or more generally FOO(func1(y)) , where func1() has side effects. The do {} block is then used as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); }
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(x);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case someone writes FOO(y++). Or more generally FOO(func(y)) , where func has side effects.
  • The do {} block is then used as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); } while (0);
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
#3: Post edited by user avatar Pete W‭ · 2020-12-17T15:34:30Z (over 3 years ago)
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(x);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded. Why declare variables inside a macro? To avoid unanticipated behavior for the caller due to macro argument getting expanded more than once. For example:
  • > #define FOO(x) do { long xx = x; func1(xx); func2(xx); }
  • Obviously there is still a type conversion issue, but that is the case just the same if you are going to be calling func1(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is mostly the same except the result is an expression rather than a statement.
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(x);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded.
  • Why declare variables inside a macro? In case someone writes FOO(y++). Or more generally FOO(func1(y)) , where func1() has side effects. The do {} block is then used as follows:
  • > #define FOO(x) do { long xx = x; func2(xx); func3(xx); }
  • Obviously there is still an assumption about type of x, but that is the case anyway if you are going to be calling func2(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is a construct in case you want the block to be an expression rather than a statement.
#2: Post edited by user avatar Pete W‭ · 2020-12-17T15:29:19Z (over 3 years ago)
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(x);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is mostly the same except the result is an expression rather than a statement.
  • Reasons to use the construct
  • > #define FOO(x) do{...} while(0);
  • (1) as mentioned above, solves the problem of
  • > if (...) FOO(x);
  • (2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded. Why declare variables inside a macro? To avoid unanticipated behavior for the caller due to macro argument getting expanded more than once. For example:
  • > #define FOO(x) do { long xx = x; func1(xx); func2(xx); }
  • Obviously there is still a type conversion issue, but that is the case just the same if you are going to be calling func1(x) etc
  • (3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is mostly the same except the result is an expression rather than a statement.
#1: Initial revision by user avatar Pete W‭ · 2020-12-17T00:01:53Z (over 3 years ago)
Reasons to use the construct

 > #define FOO(x) do{...} while(0);


(1) as mentioned above, solves the problem of


 > if (...) FOO(x);

(2) you get to declare more variables inside the block, and they harmlessly go out of scope at the end of the block. Without the do{} block, the same symbol would cause a warning (or worse) if it were declared in the same block in which FOO(x) gets expanded
 
(3) Without the do{} block, there might be ambiguity as to whether FOO(x) expands into a statement or an expression. do{} makes it clearly a statement, which can help catch someone trying to use FOO(x) where an expression is expected. See also: "statement-expressions", aka ({...}), which is mostly the same except the result is an expression rather than a statement.