Re: memcpy as macro legit?
From: Lawrence Kirby (lknews_at_netactive.co.uk)
Date: 11/25/04
- Next message: Chris Croughton: "Re: assert(x) and '#define ASSERT(x) assert(x)'"
- Previous message: Matt: "Re: Systems software versus applications software definitions"
- In reply to: Keith Thompson: "Re: memcpy as macro legit?"
- Next in thread: Peter Nilsson: "Re: memcpy as macro legit?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 25 Nov 2004 15:00:18 +0000
On Fri, 19 Nov 2004 20:41:54 +0000, Keith Thompson wrote:
> Lawrence Kirby <lknews@netactive.co.uk> writes:
>> On Fri, 19 Nov 2004 04:27:17 -0500, Michael B Allen wrote:
>>
>>> I just noticed that doing something like the following may fail because
>>> it can overwrite u->size before it's evaluated.
>>>
>>> memcpy(u, buf, u->size);
>>>
>>> Is it legit that this is a macro as opposed to a function that would
>>> not clobber the parameter?
>>
>> Any standard library function can have a macro definition in the relevant
>> standard header. However the macro must still preserve the semantic of the
>> function, and as a function it cannot modify its arguments.
>
> A function can modify one of its arguments if another argument points
> to it (though you have to be careful about undefined behavior).
Not really, which is obvious when you stop to consider that the argument
to a function is a value, not an lvalue. Consider
int x = 42;
then
f(x, &x);
and
f(x+0, &x);
are equivalient in C (for fun don't forget f(+x, &x)). Is x the argument
in all of these? No, but its value is. From this perspective talking about
modifying a function's argument makes no sense - there is nothing to
modify; a value has no persistence, only the contents of an object and
things hidden behind standard library functions (such as streams) do.
However "a function cannot modify its arguments" is a common enough
assertion, so what does it mean? Maybe "IF you supply an lvalue as a
function argument the function cannot use that lvalue to modify what it
designates". Naturally modifying the designated object through an lvalue
derived by some other means is possible.
> There could also be issued with sequence points. C99 7.1.4p1 says:
>
> Any invocation of a library function that is implemented as a
> macro shall expand to code that evaluates each of its arguments
> exactly once, fully protected by parentheses where necessary, so
> it is generally safe to use arbitrary expressions as arguments.
>
> with a footnote:
>
> Such macros might not contain the sequence points that the
> corresponding function calls do.
>
> For example, the expression sin(x) + cos(x) can invoke undefined
> behavior because both calls can set errno, and if sin() and cos() are
> implemented as macros there may not be a sequence point where it's
> needed. There was a discussion of this in comp.std.c a few years
> ago; see
> <http://groups.google.com/groups?as_umsgid=%3Cyecr9j8ghg6.fsf@king.cts.com%3E>
True that is another area where macros for standard library functions can
behave differently.
Lawrence
- Next message: Chris Croughton: "Re: assert(x) and '#define ASSERT(x) assert(x)'"
- Previous message: Matt: "Re: Systems software versus applications software definitions"
- In reply to: Keith Thompson: "Re: memcpy as macro legit?"
- Next in thread: Peter Nilsson: "Re: memcpy as macro legit?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
