macros and side effects

[copx]

Is it true that C macros are unsafe when combined with side effects even if
they are "clean" e.g. could

foo_macro(++c);

execute "++c" multiple times even if foo_macro is "clean"? I have always
thought that "clean" macros (i.e. macros where all parameters are
surrounded by parentheses in the definition) do not have this problem...

I am wondering because I have just looked up putc() in a reference, and it
says that it is unsafe if the "passed" value has a side effect, and I assume
standard macros are "clean"...

[Charlton Wilbur]

>>>>"c" == copx <co**@gazeta.pl writes:

cIs it true that C macros are unsafe when combined with side
ceffects even if they are "clean" e.g. could

cfoo_macro(++c) ;

#define foo_macro(x) (x)*(x)

Whoops.

Charlton

--
Charlton Wilbur
cw*****@chromat ico.net

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

copx wrote:

Is it true that C macros are unsafe when combined with side effects even if
they are "clean" e.g. could

foo_macro(++c);

execute "++c" multiple times even if foo_macro is "clean"? I have always
thought that "clean" macros (i.e. macros where all parameters are
surrounded by parentheses in the definition) do not have this problem...

I am wondering because I have just looked up putc() in a reference, and it
says that it is unsafe if the "passed" value has a side effect, and I assume
standard macros are "clean"...

Your reference is correct, and "clean" macros can evaluate their
arguments multiple times. As a simple example, if you have

#define foo_macro(x) ((x) * (x))

then foo_macro's arguments are fully parenthesised, but foo_macro(++c)
will still expand to ((++c) * (++c)).

For most standard library functions, it is required that if they are
also implemented as a macro, that that macro evaluates each argument
exactly once. putc is an exception.

[Richard Heathfield]

copx said:

Is it true that C macros are unsafe

Not if written correctly and used correctly.

when combined with side effects even if they are "clean" e.g. could

foo_macro(++c);

execute "++c" multiple times even if foo_macro is "clean"?

That is not a widely-used term for describing macros. (Translation: it's
the first time I have ever seen it.)

I have
always
thought that "clean" macros (i.e. macros where all parameters are
surrounded by parentheses in the definition) do not have this
problem...

You thought wrong.

I am wondering because I have just looked up putc() in a reference,
and it says that it is unsafe if the "passed" value has a side effect,

Your reference says wrong. The putc function, if implemented as a macro,
may evaluate the stream more than once, but *not* the character. And
you're hardly likely to call it as putc('\n', fp++), I trust?

and I assume standard macros are "clean"...

Why?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Heathfield wrote:

copx said:

I am wondering because I have just looked up putc() in a reference,
and it says that it is unsafe if the "passed" value has a side effect,

Your reference says wrong. The putc function, if implemented as a macro,
may evaluate the stream more than once, but *not* the character.

That's a useful clarification, but it doesn't mean the reference is
wrong.

[Eric Sosman]

Richard Heathfield wrote On 05/04/07 12:34,:

copx said:

>>[...] "clean" macros (i.e. macros where all parameters are
surrounded by parentheses in the definition) [...]

and I assume standard macros are "clean"...

Why?

Perhaps because of the Standard? 6.10.8 lists the
values of the predefined macros, and all are "clean."
7.1.2p5 requires "cleanlines s" of all object-like macros
defined in the standard headers, and 7.1.4p2 does the same
for function-like macros that implement standard library
functions. What remains are the dribs and drabs like
va_start() and setjmp(); do you find them "unclean" (in
the O.P.'s sense, that is)?

--
Er*********@sun .com

[Dave Vandervies]

In article <gP************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>copx said:

>Is it true that C macros are unsafe

Not if written correctly and used correctly.

It's worth noting, though, that they're one of the easier parts of the
language to get wrong unintentionally , and it's sometimes easy to convert
correct use into incorrect use without realizing it, even if you do know
what you're doing.

If you compare programming in C to running with scissors, a lot of code
that uses macros ends up being at the pointy end of the scissors.
dave
(runs around the pool with scissors)

--
Dave Vandervies dj******@csclub .uwaterloo.ca
C is for people who run with scissors on a daily basis without cutting
themselves, because they know how to be careful around sharp tools.
--Richard Heathfield in comp.lang.c

[Bart van Ingen Schenau]

copx wrote:

Is it true that C macros are unsafe when combined with side effects
even if they are "clean" e.g. could

foo_macro(++c);

execute "++c" multiple times even if foo_macro is "clean"?

Yes.

I have
always
thought that "clean" macros (i.e. macros where all parameters are
surrounded by parentheses in the definition) do not have this
problem...

Because macros are essentially a form of text substitution, the
parentheses in a macro definition can not influence how often an
argument gets evaluated.

The parentheses around macro arguments are needed to ensure that the
parser always interprets the complete argument as a single expression.
For example, take these two macros:

#define HALVE(x) x/2
#define DIVIDE_BY_TWO(x ) (x)/2

When you use them like this:

y = HALVE(3+1);
z = DIVIDE_BY_TWO(3 +1);

the preprocessor will replace the macros, yielding:

y = 3+1/2;
z = (3+1)/2;

Do you see the difference between the two statements?

>
I am wondering because I have just looked up putc() in a reference,
and it says that it is unsafe if the "passed" value has a side effect,
and I assume standard macros are "clean"...

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[copx]

"Bart van Ingen Schenau" <ba**@ingen.ddn s.infoschrieb im Newsbeitrag
news:60******** ********@ingen. ddns.info...

copx wrote:

>Is it true that C macros are unsafe when combined with side effects
even if they are "clean" e.g. could

foo_macro(++c) ;

execute "++c" multiple times even if foo_macro is "clean"?

Yes.

>I have
always
thought that "clean" macros (i.e. macros where all parameters are
surrounded by parentheses in the definition) do not have this
problem...

Because macros are essentially a form of text substitution, the
parentheses in a macro definition can not influence how often an
argument gets evaluated.

The parentheses around macro arguments are needed to ensure that the
parser always interprets the complete argument as a single expression.
For example, take these two macros:

#define HALVE(x) x/2
#define DIVIDE_BY_TWO(x ) (x)/2

When you use them like this:

y = HALVE(3+1);
z = DIVIDE_BY_TWO(3 +1);

the preprocessor will replace the macros, yielding:

y = 3+1/2;
z = (3+1)/2;

Do you see the difference between the two statements?

[snip]

Yes, I remember that much of kindergarten math ;)

Thanks everyone.

[Fred Kleinschmidt]

"Harald van D?k" <tr*****@gmail. comwrote in message
news:11******** **************@ c35g2000hsg.goo glegroups.com.. .

copx wrote:

>Is it true that C macros are unsafe when combined with side effects even
if
they are "clean" e.g. could

foo_macro(++c) ;

execute "++c" multiple times even if foo_macro is "clean"? I have always
thought that "clean" macros (i.e. macros where all parameters are
surrounded by parentheses in the definition) do not have this problem...

I am wondering because I have just looked up putc() in a reference, and
it
says that it is unsafe if the "passed" value has a side effect, and I
assume
standard macros are "clean"...

Your reference is correct, and "clean" macros can evaluate their
arguments multiple times. As a simple example, if you have

#define foo_macro(x) ((x) * (x))

then foo_macro's arguments are fully parenthesised, but foo_macro(++c)
will still expand to ((++c) * (++c)).

For most standard library functions, it is required that if they are
also implemented as a macro, that that macro evaluates each argument
exactly once. putc is an exception.

Not "exactly once", but "at most once". It is quite legitimate for
some argument to not be evaluated at all.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Aero Stability and Controls Computing