{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

3.10 macro pitfalls in this section we describe some

Info iconThis preview shows pages 38–40. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 3.10 Macro Pitfalls In this section we describe some special rules that apply to macros and macro expansion, and point out certain cases in which the rules have counter-intuitive consequences that you must watch out for. 3.10.1 Misnesting When a macro is called with arguments, the arguments are substituted into the macro body and the result is checked, together with the rest of the input file, for more macro calls. It is possible to piece together a macro call coming partially from the macro body and partially from the arguments. For example, #define twice(x) (2*(x)) #define call_with_1(x) x(1) call_with_1 (twice) 7→ twice(1) 7→ (2*(1)) Macro definitions do not have to have balanced parentheses. By writing an unbalanced open parenthesis in a macro body, it is possible to create a macro call that begins inside the macro body but ends outside of it. For example, #define strange(file) fprintf (file, "%s %d", ... strange(stderr) p, 35) 7→ fprintf (stderr, "%s %d", p, 35) The ability to piece together a macro call can be useful, but the use of unbalanced open parentheses in a macro body is just confusing, and should be avoided. 3.10.2 Operator Precedence Problems You may have noticed that in most of the macro definition examples shown above, each occurrence of a macro argument name had parentheses around it. In addition, another pair of parentheses usually surround the entire macro definition. Here is why it is best to write macros that way. Suppose you define a macro as follows, #define ceil_div(x, y) (x + y - 1) / y whose purpose is to divide, rounding up. (One use for this operation is to compute how many int objects are needed to hold a certain number of char objects.) Then suppose it is used as follows: a = ceil_div (b & c, sizeof (int)); 7→ a = (b & c + sizeof (int) - 1) / sizeof (int); This does not do what is intended. The operator-precedence rules of C make it equivalent to this: Chapter 3: Macros 35 a = (b & (c + sizeof (int) - 1)) / sizeof (int); What we want is this: a = ((b & c) + sizeof (int) - 1)) / sizeof (int); Defining the macro as #define ceil_div(x, y) ((x) + (y) - 1) / (y) provides the desired result. Unintended grouping can result in another way. Consider sizeof ceil_div(1, 2) . That has the appearance of a C expression that would compute the size of the type of ceil_div (1, 2) , but in fact it means something very different. Here is what it expands to: sizeof ((1) + (2) - 1) / (2) This would take the size of an integer and divide it by two. The precedence rules have put the division outside the sizeof when it was intended to be inside. Parentheses around the entire macro definition prevent such problems. Here, then, is the recommended way to define ceil_div : #define ceil_div(x, y) (((x) + (y) - 1) / (y)) 3.10.3 Swallowing the Semicolon Often it is desirable to define a macro that expands into a compound statement. Consider, for example, the following macro, that advances a pointer (the argument p says where to find it) across whitespace characters:...
View Full Document

{[ snackBarMessage ]}

Page38 / 83

3.10 Macro Pitfalls In this section we describe some...

This preview shows document pages 38 - 40. Sign up to view the full document.

View Full Document Right Arrow Icon bookmark
Ask a homework question - tutors are online