Actions

icon Post
text/html Subscribe
text/html Unsubscribe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cxx-abi-dev] non-public non-static members vs POD layout


  • To: mark@xxxxxxxxxxxxxxxx, scott.douglass@xxxxxxx
  • Subject: Re: [cxx-abi-dev] non-public non-static members vs POD layout
  • From: Dennis Handly <dhandly@xxxxxxxxxx>
  • Date: Mon, 28 Apr 2008 18:03:58 -0700 (PDT)

>From: Mark Mitchell <mark@xxxxxxxxxxxxxxxx>
>Also since the ABI predates TC1, the inclusion of pointers to members  
>on PODs should not apply. I suppose the spec would explicitly say  
>"PODs as defined prior to TC1"
>Does anyone object to making that change?

I thought I pointed out the TC1 change before and there was comments that
the ABI should accept the change??

Here are some words:
! The ISO C++ standard published in 1998 had a different definition of
! POD types.  In particular, a class with a non-static data member of
! pointer-to-member type was not considered a POD in C++98, but is
! considered a POD in TC1.  Because the C++ standard requires that
! compilers not overlay the tail padding in a POD, using the C++98
! definition in this ABI would prevent a conforming compiler from
! correctly implementing the TC1 version of the C++ standard.
! Therefore, this ABI uses the TC1 definition of POD.</dd>

And before that:
Mark Mitchell wrote:
> Yes, you're correct, the standard does guarantee that you can do
> bitwise copies for PODs  using their size.
> In other words, your point is that unless we interpret the ABI as
> meaning "TC1 POD", it is not the ABI for a correct C++ compiler,
> because it will fall afoul of this rule.  This is [basic.types]/3, for
> reference.
>
> I think that's a pretty compelling agument that we should clarify the
> ABI to indicate that POD means "POD as defined by TC1".  Any
> objections to that proposal?  Are there any compilers other than aCC
> implementing the pre-TC1 definition?

Nobody objected, so I committed the following change, requiring the TC1
definition.  The change will be reflected in the online copy shortly.  I
also clarified the fact that an array that is a POD type, but whose
elements are not a POD for the purpose of layout is not itself a POD for
the purpose of layout.