Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2001-07-03 14:46:34


> > Could you elaborate on this? I've never heard before that arrays of char
> > can't be copied, but arrays of unsigned char can be. Is this really what
> > you meant to say?
>
> Yes. The following is not well defined:
>
> struct X {
> char a[20];
> };
> X x;
> X y = x;
>
> The reason is that the array is copied member wise, char by
> char, and copying an uninitialised char is undefined behaviour,
> just like float. The ONLY (primitive) type you can use uninitialised
> is unsigned char (which has an unspecified value, but the value
> is guarranteed to be a valid unsigned char).

I'm just going to jump in and clarify this a little: John's saying that an
*uninitialized* character cannot be used as the source of an assignment. At
first I thought 'no way!', but it's true. Furthermore, I'm not convinced
that using an unsigned char would fix it.

Here's the problem statement:
[4.1/1] "An lvalue ... can be converted to an rvalue... [I]f the object is
uninitialized, a program that necessitates this conversion has undefined
behavior..."
OK, so copying from uninitialized values results in undefined behavior.
This would be applicable to all POD types (incl. unsigned chars).

I'm assuming that John is depending on following quote to support using
unsigned chars in this fashion:
[3.9.1/1] "... For unsigned character types, all possible bit patterns of
the value representation represent numbers. These requirements do not hold
for other types..."

but I think that [4.1/1] would still hold, even for unsigned characters.

        -Steve


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk