g++ and aliasing bools

[Joe Buck]

I wrote:
> > But the C aliasing rules completely ignore the question of size, so you're
> > bringing up a red herring.  The rules have *nothing* to do with whether we
> > think that two objects have the same address!  It doesn't even come up.
> > For that reason, you don't have to waste any time thinking about class
> > layout.

Mark writes:
> Joe's argument is a reduction from C++ to C; the claim is that (basically)
> the C++ alias rules are the same as C and that certain C++ classes are
> laid out like certain C structs and that there are no additional
> "dangerous" operations and therefore correctness for C implies correctness
> for C++.
> 
> The argument doesn't work in this case -- the proposed isomorphism from
> C++ classes to C structs is not correct.

But for the purpose of isomorphism one can ignore features that don't
matter.  Consider a translation from C++ to C that does not create
zero-sized structs.  A C++ implementation is free to waste space.  Such a
translation is legal and will produce a standard C program.  C's aliasing
analysis will work on such a program, correct?

Now, it seems you are telling me that you fear that the aliasing rules
could change if we optimize the implementation to not waste space,
effectively making some fields that originally had size > 0 now have
size 0.  But this cannot be the case, because both the C and the C++
aliasing rules are based solely on the types, not on the layouts.

> Joe's argument either needs to handle zero-sized classes in some other
> way (arguing that they're not dangerous for some other reason), or it
> needs to not apply to class hierarchives that involve zero-sized bases,
> treating such things as not simple_enough.

The basic argument is this: I am allowed to implement C++ in a way that
zero-sized classes don't exist (they always come out as at least one
byte).  For such implementations I can clearly use the C rules, as there
is an equivalent C program.  If I then replace the inefficient
implementation with an efficient one, the language specification does not
care, for the purpose of aliasing.  The type-based aliasing rules are
independent of implementation, so if they come out correctly for the
inefficient implementation, we get the same answer for the efficient one.