va_copy

[REH]

Is there a standard when to implement va_copy in the pre-99 standard? Is
this allowed by the standard:

#define va_copy(DEST, SRC) memcpy((DEST), (SRC), sizeof(va_list))
Thanks.

[Ben Pfaff]

"REH" <[e-mail]> writes:

Is there a standard when to implement va_copy in the pre-99 standard? Is
this allowed by the standard:

#define va_copy(DEST, SRC) memcpy((DEST), (SRC), sizeof(va_list))

It's not obvious to me why that couldn't be a conforming
implementation of va_copy. However, I wonder whether you really
mean "can I implement it this way?" In general, no: there is no
guarantee that this will have the desired effect.
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield

[Chris Torek]

>"REH" <[e-mail]> writes:

Is there a standard when to implement va_copy in the pre-99 standard? Is
this allowed by the standard:

#define va_copy(DEST, SRC) memcpy((DEST), (SRC), sizeof(va_list))

In article <87************@benpfaff.org>
Ben Pfaff <bl*@cs.stanford.edu> wrote:It's not obvious to me why that couldn't be a conforming
implementation of va_copy.
Well, almost:

#define va_copy(dst, src) \
((void) memcpy((dst), (src), sizeof(va_list)))

because C99 says that, while va_copy is a macro, it acts as if it
were a void-valued function.
However, I wonder whether you really mean "can I implement it this
way?" In general, no: there is no guarantee that this will have
the desired effect.

Indeed. In particular, it will not work on implementations in
which "va_list" is a typedef alias for "char *", such as most
Intel-x86 systems.

There is always some way to define va_copy() that will work, but
the actual definition needs to change from one platform to the next.
The two most common definitions are the memcpy above, and the
even simpler:

#define va_copy(dst, src) ((void)((dst) = (src)))

Without knowing how the compiler implements va_list, va_start, etc.,
it is impossible to tell which of these two common definitions will
work (or whether a different, uncommon, definition is required).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Peter Nilsson]

> >"REH" <[e-mail]> writes:

Is there a standard when to implement va_copy in the pre-99 standard? Is this allowed by the standard:

#define va_copy(DEST, SRC) memcpy((DEST), (SRC), sizeof(va_list))

Ben Pfaff <bl*@cs.stanford.edu> wrote:

It's not obvious to me why that couldn't be a conforming
implementation of va_copy.

Chris Torek wrote: Well, almost:

#define va_copy(dst, src) \
((void) memcpy((dst), (src), sizeof(va_list)))

because C99 says that, while va_copy is a macro, it acts as if it
were a void-valued function.

How would a strictly conforming program tell the difference?

--
Peter

[Chris Torek]

>Chris Torek wrote:

[I inserted a (void) cast in a memcpy()]
... C99 says that, while va_copy is a macro, it acts as if it
were a void-valued function.

In article <11**********************@o13g2000cwo.googlegroups .com>
Peter Nilsson <ai***@acay.com.au> wrote:How would a strictly conforming program tell the difference?

This is a bit of an odd situation, really.

Without the cast, you could feed an "invalid" translation unit --
one that requires a diagnostic, that is -- to a compiler and perhaps
get no diagnostic:

void vfunc(const char *fmt, ...) {
va_list va1, va2;

va_start(fmt, va1);

void *p = va_copy(va1, va2);
/* more code here */
}

But a compiler is always free to emit bogus diagnostics, so even
if we remove the "void *p =" part, we could still get a diagnostic.

This means there is no *guaranteed* way to discover that va_copy()
is mis-#defined, and we cannot write a strictly conforming program
to find out.

Still, whenever we (C programmers) play the role of "implementor",
writing some or all of a C compiler, we should at least strive to
give useful diagnostics. Defining va_copy without the (void) cast
will usually omit the useful diagnostic, and -- depending on the
compiler -- might even omit the required one.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.