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

[Moore, David]

Yes - I did miss that change. Or perhaps its significance - I had to
think twice about it to see that it covered the case. All it really
needs to say is "If C is a POD, set nvsize(C) = sizeof(C)". Then the
fact that you have the desired post condition is easier to see. 

If I understand your more fundamental point, what you are saying is that
if the form of wording adopted and my alternative produced different
results, we would have a bug in the ABI. Or, to state it differently,
you should be able to push a POD through the non-POD layout method and
get the same layout. If so, I certainly agree with that. I think we are
ok on that front given 2.4.IV.



-----Original Message-----
From: Mark Mitchell [mailto:mark at codesourcery.com] 
Sent: Thursday, May 22, 2003 11:30 AM
To: Moore, David
Cc: cxx-abi-dev at codesourcery.com
Subject: RE: [cxx-abi-dev] PATCH: Define "POD for the purpose of layout"

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