Re: [boost] arrays of char can't be copied?

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-07-04 15:05:44

scleary_at_[hidden] wrote:

> >       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.  

        Or a copy.

> At first I thought 'no way!', but it's true.  Furthermore, I'm not convinced
> that using an unsigned char would fix it.

        It does. The C++ committee took great care to make sure
of it, and I think C (at least C99) is the same.

> 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..."

        This may be a defect, but the rules are confusing 
because they're written by programmers, not scientists who 
understand modelling :-)

> 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..."

        There are TWO kinds of bit.

        1. A logical bit
        2. A representation bit.

For an unsigned type, bit n is uniquely determined by 

        bit 0 x = x % 2
        bit n x = x % 2^(n+1) - bit (n-1) x

This kind of bit is used for all bitwise operations.
The second kind of bit is determined by examining

        union {
                unsigned char u[sizeof(T)];
                T x;
        };

There is a requirement that copying u will copy x,
for all POD types T. It is this requirement that
defined 'representation bit', as 'logical bit
of the underlying unsigned char array'.

3.9.1/1 is trying to say the above in a different way.

[The _correct_ way to say this would involve saying that
there is a surjective mapping from u to x in the union:
this completely avoids talking about representation
bits]

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net