Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>> A type is a standard-layout type, or it isn't.
>>>
>>> How about "An empty record is standard-layout Plain Old Data (POD)
>>> type and ..."?
>>
>> That's redundant, all POD types are standard-layout types.
>>
>
> Apparently, not all standard-layout types are POD types.  GCC has
>
> /* Nonzero means that this class type is not POD for the purpose of layout
>    (as defined in the ABI).  This is different from the language's POD.  */
> CLASSTYPE_NON_LAYOUT_POD_P
>
> and
>
> /* Nonzero means that this class type is a non-standard-layout class.  */
> #define CLASSTYPE_NON_STD_LAYOUT
>
> They aren't the same.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type, but not a standard-layout POD type.

As the comment says, "POD for the purposes of layout" is different
from the language's POD. All standard-layout types are POD types
according to the language.

So when you previously had "POD for the purposes of layout" that was
at least partially clear that you meant something other than what the
language means. But as pointed out, using a GCC-specific term is not
ideal.

When you changed it to "POD for the purpose of standard-layout" that
became a completely meaningless term. Where is that defined?

Your next suggestion was "standard-layout Plain Old Data (POD)" which
is even worse, now you're using two terms defined by the C++ language,
but you mean something different.

When you mean something that is the same as the language (like "class
type") it makes sense to use the same term.

When you mean something that is not the same as the language (like
"POD") it makes sense to use a different term, or clearly define how
you are using it.