[cxx-abi-dev] PATCH: Define "POD for the purpose of layout"

[Mark Mitchell]

On Thu, 2003-05-22 at 11:18, Moore, David wrote:
> That a POD type for the purposes of layout could contain a non-POD type
> for the purposes of layout seems ugly.
>  
> More seriously this is a substantive change that produces a binary
> incompatibility. Consider:
>  
> struct A { int i : 2048; short j};
>  
> struct B : public A {short k;}
>  
> With the revised rule, because A is a non-POD type for the purposes of
> layout, its tail padding will be reused in the layout of B. Hence
> sizeof(B)= 264 at present but will be 260 with the change to the ABI.

I think you missed the change at the end of 2.4.IV:

"Round sizeof(C) up to a non-zero multiple of align(C). If C is a POD,
but not a POD for the purpose of layout, set nvsize(C) = sizeof(C)."

It would be incorrect not to update nvsize, not only because of the
incompatibility you mention, but because of the more fundamental issue
that the ISO C++ does not allow tail-padding reuse for PODs.

There's a more fundamental point, which is that if the basic rules for
laying out data members in PODs don't match up with those for laying out
data members in non-PODs, people will be surprised.  In other words, if
these two classes:

  /* A is a POD.  */
  struct A { int i; double d; char c; };
  /* B is not a POD.  */
  struct B { B(); int i; double d; char c; };

do not have the same layout people will be surprised.

Technically, that is possible with the C++ ABI because of the
POD/non-POD split.  However, the authors of the C++ ABI anticipated that
if you followed the non-POD rules for PODs you would get the same layout
as you would for PODs, modulo nvsize.  If that assumption holds on your
platform, then you don't have to keep track of "non-POD-for-the-purposes
of layout".

It's also not clear me how to formalize your suggestion ("do what the C
ABI says except use 2.4.II.1 for an overlong bitfield").

-- 
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com