Skip to content

Commit b6a1618

Browse files
committed
book: don’t use GNU extensions in the example unnecessarily
The use of a GNU C extension for bloc expressions is immaterial to the actual problem with C macros that the section tries to show so don’t use it and instead use a plain C way of writing the macro.
1 parent e0044bd commit b6a1618

File tree

1 file changed

+6
-8
lines changed

1 file changed

+6
-8
lines changed

src/doc/book/src/macros.md

+6-8
Original file line numberDiff line numberDiff line change
@@ -261,36 +261,34 @@ The metavariable `$x` is parsed as a single expression node, and keeps its
261261
place in the syntax tree even after substitution.
262262

263263
Another common problem in macro systems is ‘variable capture’. Here’s a C
264-
macro, using [a GNU C extension] to emulate Rust’s expression blocks.
265-
266-
[a GNU C extension]: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
264+
macro using a block with multiple statements.
267265

268266
```text
269-
#define LOG(msg) ({ \
267+
#define LOG(msg) do { \
270268
int state = get_log_state(); \
271269
if (state > 0) { \
272270
printf("log(%d): %s\n", state, msg); \
273271
} \
274-
})
272+
} while (0)
275273
```
276274

277275
Here’s a simple use case that goes terribly wrong:
278276

279277
```text
280278
const char *state = "reticulating splines";
281-
LOG(state)
279+
LOG(state);
282280
```
283281

284282
This expands to
285283

286284
```text
287285
const char *state = "reticulating splines";
288-
{
286+
do {
289287
int state = get_log_state();
290288
if (state > 0) {
291289
printf("log(%d): %s\n", state, state);
292290
}
293-
}
291+
} while (0);
294292
```
295293

296294
The second variable named `state` shadows the first one. This is a problem

0 commit comments

Comments
 (0)