Re: C ABI: struct/union inconsistency

Re: C ABI: struct/union inconsistency

[Robert Dewar]

Ada allows null reocrds but an interesting glitch is that they cannot
be allocated with zero size, since access to separate objects must
yield separate pointers.

Re: C ABI: struct/union inconsistency

[Gabriel Dos Reis]

Gabriel Paubert <paubert@iram.es> writes:

[...]

| struct S2 {void};
| 
| whose size would _always_ be zero in C, C++, ObjC, ObjC++, C#...

I would oppose to damaging the already complicated grammar just to
support what we could describe with an attibute.

[...]

| Let me grab my asbestos suit before the flamefest starts.

:-) :-)

-- Gaby

Re: C ABI: struct/union inconsistency

[Gabriel Paubert]

Mark Mitchell wrote:
>>     struct foo {
>>     #ifdef SMP
>>         long long count;
>>         long lock;
>>     #endif
>>     };
>>
>> Here, attribute((nopadding)) would leave foo with size 12,
>> instead of the required size 16 when SMP is defined.
> 
> 
> Ah, good point.
> 
> I hate it when I think I'm clever and then turn out not to be.
> 

Hmm, what about attribute((collapse)),  or collapse_empty_struct,
or something similar. I'm not a native english speaker, but I kind
of like the word "collapse" to describe this property. However I
may have been brainwashed by cosmologists in a previous life :-)

<devil>

Alternatively, it could be said that sizeof (struct S1 {}) is always
one, and we could invent a new syntax for zero sized structs

struct S2 {void};

whose size would _always_ be zero in C, C++, ObjC, ObjC++, C#...

Oh well, yet another devious GNU C-only syntax extension proposal.
Let me grab my asbestos suit before the flamefest starts.

</devil>

	Regards,
	Gabriel.

Re: C ABI: struct/union inconsistency

[Tim Hollebeek]

> > We _only_ want to change the zero-size-ness of this struct.
> 
> Well, this can handled:
> 
> #ifndef SMP
>         __attribute__(nopadding)__
> #endif
> 
> That is not to say whether re-using nopadding for two (related)
> purposes would be a good idea or not, but we *could* do so.

The bar for introducing an new attribute should be high.

if __attribute__(nopadding) is used to control whether an empty
structure gets "padded" to one byte, then the definition of certain
structures which were intended to be zero size if empty, but PADDED if
not, becomes more complicated.

Why does that not worry me too much?

"We only want to change the zero-sized-ness of this struct" is an
indefensible position, and one for which no justification was ever
offered.

-Tim

Re: C ABI: struct/union inconsistency

[Alexandre Oliva]

On Sep 27, 2002, "David S. Miller" <davem@redhat.com> wrote:

> How about "invisible"

Would be misleading because of the existing, unrelated `visibility'
attribute.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: C ABI: struct/union inconsistency

[Per Bothner]

Richard Henderson wrote:
> No, that's not what we want.
> 
> 
> 	struct foo {
> 	#ifdef SMP
> 		long long count;
> 		long lock;
> 	#endif
> 	};
> 
> Here, attribute((nopadding)) would leave foo with size 12, 
> instead of the required size 16 when SMP is defined.
> 
> We _only_ want to change the zero-size-ness of this struct.

Well, this can handled:

#ifndef SMP
        __attribute__(nopadding)__
#endif

That is not to say whether re-using nopadding for two (related)
purposes would be a good idea or not, but we *could* do so.

Another (wild) idea:  Allow "negative" dizes - or fields that
don't count to the final size:

struct foo {
   int a;
   __size_cutoff_;
   int b;
};

In this case, sizeof(struct foo)==sizeof(int).  If you access a 'b',
it will be actually be access from the *next* field.  This would
be like:

struct foo {
   int a;
   int __b[0];
};

except b is not an array.

Note:  I don't say this is a terribly useful feature - but then some
would say that empty structs aren't terribly useful either.

Then an empty struct is:
struct foo {
   __size_cutoff;
:;
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: C ABI: struct/union inconsistency

[Mark Mitchell]

> 	struct foo {
> 	#ifdef SMP
> 		long long count;
> 		long lock;
> 	#endif
> 	};
>
> Here, attribute((nopadding)) would leave foo with size 12,
> instead of the required size 16 when SMP is defined.

Ah, good point.

I hate it when I think I'm clever and then turn out not to be.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C ABI: struct/union inconsistency

[Richard Henderson]

On Sat, Sep 28, 2002 at 10:36:01AM -0700, Mark Mitchell wrote:
> >Don't we already have (or recently discuss) an attribute to eliminate
> >tail padding?  Shouldn't that get used here?
> 
> Yes, I realized last night that attribute((nopadding)) is the right
> answer to this question.  I'd been meaning to implement that anyhow;
> this is an opportune excuse.

No, that's not what we want.


	struct foo {
	#ifdef SMP
		long long count;
		long lock;
	#endif
	};

Here, attribute((nopadding)) would leave foo with size 12, 
instead of the required size 16 when SMP is defined.

We _only_ want to change the zero-size-ness of this struct.


r~

Re: C ABI: struct/union inconsistency

[Mark Mitchell]

--On Saturday, September 28, 2002 10:06:55 AM -0700 Tim Hollebeek 
<tim@hollebeek.com> wrote:

> On Fri, Sep 27, 2002 at 06:46:05PM -0700, Richard Henderson wrote:
>> On Fri, Sep 27, 2002 at 06:11:37PM -0700, Mark Mitchell wrote:
>> > > How about "invisible", we're making the zero sized members
>> > > invisible :-)
>> >
>> > That's cute.
>>
>> Cute, but not very descriptive.  allow_zero_size?
>
> Don't we already have (or recently discuss) an attribute to eliminate
> tail padding?  Shouldn't that get used here?

Yes, I realized last night that attribute((nopadding)) is the right
answer to this question.  I'd been meaning to implement that anyhow;
this is an opportune excuse.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C ABI: struct/union inconsistency

[Tim Hollebeek]

On Fri, Sep 27, 2002 at 06:46:05PM -0700, Richard Henderson wrote:
> On Fri, Sep 27, 2002 at 06:11:37PM -0700, Mark Mitchell wrote:
> > >How about "invisible", we're making the zero sized members
> > >invisible :-)
> > 
> > That's cute.
> 
> Cute, but not very descriptive.  allow_zero_size?

Don't we already have (or recently discuss) an attribute to eliminate
tail padding?  Shouldn't that get used here?

sizeof(struct __attribute__(no_tail_padding) { } ) == 0

seems intuitive to me.

-Tim

Re: C ABI: struct/union inconsistency

[Fergus Henderson]

On 27-Sep-2002, Mark Mitchell <mark@codesourcery.com> wrote:
> 
> --On Friday, September 27, 2002 06:05:16 PM -0700 "David S. Miller" 
> <davem@redhat.com> wrote:
> >How about "invisible", we're making the zero sized members
> >invisible :-)
> 
> That's cute.
> 
> I'll go with that one, unless someone comes up with a better one.

I prefer the suggestion of "allow_zero_size".

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: C ABI: struct/union inconsistency

[Hans-Peter Nilsson]

Oh! oh!  Me too!

On Fri, 27 Sep 2002, David S. Miller wrote:

>    From: Mark Mitchell <mark@codesourcery.com>
>    Date: Fri, 27 Sep 2002 16:23:54 -0700
>
>    How about "tiny"?
>
> How about "invisible", we're making the zero sized members

How about that one:    zero_sized_members ^
It's not like you'd write that very often, so it's better
descriptive than short...

brgds, H-P

Re: C ABI: struct/union inconsistency

[Michael S. Zick]

On Friday 27 September 2002 08:11 pm, Mark Mitchell wrote:
> --On Friday, September 27, 2002 06:05:16 PM -0700 "David S. Miller"
>
> <davem@redhat.com> wrote:
> >    From: Mark Mitchell <mark@codesourcery.com>
> >    Date: Fri, 27 Sep 2002 16:23:54 -0700
> >
> >    How about "tiny"?
> >
> > How about "invisible", we're making the zero sized members
> > invisible :-)
>
> That's cute.
>
> I'll go with that one, unless someone comes up with a better one.
Hmm...
Without content or size == __clueless__
Mike

Re: C ABI: struct/union inconsistency

[Richard Henderson]

On Fri, Sep 27, 2002 at 06:11:37PM -0700, Mark Mitchell wrote:
> >How about "invisible", we're making the zero sized members
> >invisible :-)
> 
> That's cute.

Cute, but not very descriptive.  allow_zero_size?


r~

Re: C ABI: struct/union inconsistency

[Mark Mitchell]

--On Friday, September 27, 2002 06:05:16 PM -0700 "David S. Miller" 
<davem@redhat.com> wrote:

>    From: Mark Mitchell <mark@codesourcery.com>
>    Date: Fri, 27 Sep 2002 16:23:54 -0700
>
>    How about "tiny"?
>
> How about "invisible", we're making the zero sized members
> invisible :-)

That's cute.

I'll go with that one, unless someone comes up with a better one.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C ABI: struct/union inconsistency

[David S. Miller]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Fri, 27 Sep 2002 16:23:54 -0700
   
   How about "tiny"?

How about "invisible", we're making the zero sized members
invisible :-)

Another option might be "sizeless".

Re: C ABI: struct/union inconsistency

[Mark Mitchell]

--On Friday, September 27, 2002 04:08:48 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Fri, Sep 27, 2002 at 02:06:49PM -0700, Mark Mitchell wrote:
>> Why not ask the kernel developers about something like:
>>
>>  struct S __attribute__((possibly_empty)) {};
>>
>> ?
>>
>> The idea being that if S has no members, the size ends up zero.
>
> As it happens, something like this was independently suggested
> by Alan Cox, so it seems that this is a reasonable solution.

Good.  I agree with the other suggestions you make, such as making
zero-sized arrays keep the whole thing having size zero.  Basically,
an attribute that preserves the current behavior.

So, the biggest remaining question is what name to use for the
attribute.  I don't think "possibly_empty" is very good.

How about "tiny"?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C ABI: struct/union inconsistency

[Richard Henderson]

On Fri, Sep 27, 2002 at 02:06:49PM -0700, Mark Mitchell wrote:
> Why not ask the kernel developers about something like:
> 
>  struct S __attribute__((possibly_empty)) {};
> 
> ?
> 
> The idea being that if S has no members, the size ends up zero.

As it happens, something like this was independently suggested
by Alan Cox, so it seems that this is a reasonable solution.

Also mentioned were arrays of such structures; to continue to
to allow arrays of one element, even if general arrays are not.

Also mentioned is

	struct some_attribute S {
		char degenerate[0];
	};

which should continue to have size zero, even though it has
a named member.


r~

Re: C ABI: struct/union inconsistency

[Mark Mitchell]

--On Friday, September 27, 2002 01:43:48 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Fri, Sep 27, 2002 at 11:52:46AM -0700, Mark Mitchell wrote:
>> My point was that I would like a header file that looks like:
>>
>> extern "C" {
>>  struct S {};
>>  ...
>> }
>>
>> to have the same meaning in both languages; that's not possible if S has
>> size zero in C.
>
> It's also not possible if one writes
>
>   extern "C" {
>     struct S {
>       const int i;
>     };
>   }
>
> as they have different meanings in C and C++.  So I don't see that your
> point necessarily holds.  The fact of the matter is that the two languages
> do not line up 100%, and one has to live with it.

That's true -- there are a few other places in the common subset that
don't line up in terms of semantics.

As far as I know, however, this empty struct issue is the only one that
has an effect on layout, which is clearly a very important issue.  Most
of the other issues result in errors in one language or the other.

If emtpy structures were rejected in C mode, I'd be much less nervous; at
least the errors would be easily detected.

Why not ask the kernel developers about something like:

  struct S __attribute__((possibly_empty)) {};

?

The idea being that if S has no members, the size ends up zero.

We could support this attribute in C++ as well, and then have
compatibility between C and C++.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C ABI: struct/union inconsistency

[Richard Henderson]

On Fri, Sep 27, 2002 at 11:52:46AM -0700, Mark Mitchell wrote:
> My point was that I would like a header file that looks like:
> 
> extern "C" {
>  struct S {};
>  ...
> }
> 
> to have the same meaning in both languages; that's not possible if S has
> size zero in C.

It's also not possible if one writes

  extern "C" {
    struct S {
      const int i;
    };
  }

as they have different meanings in C and C++.  So I don't see that your
point necessarily holds.  The fact of the matter is that the two languages
do not line up 100%, and one has to live with it.

I'll ask some kernel developers what they think of this issue, but I
suspect that they'll be in favour of the status quo, and I'll have a
hard time arguing against that "merely" for compatibility with C++.


r~

Re: C ABI: struct/union inconsistency

[Mark Mitchell]

--On Friday, September 27, 2002 08:14:48 PM +0200 Gabriel Dos Reis 
<gdr@integrable-solutions.net> wrote:

> Richard Henderson <rth@redhat.com> writes:
>
> [...]
>
> | > That means we lose C/C++ compatibility even for a type which is in
> | > the common subset of both languages.
> |
> | Compatibility between C and C++ is interesting from a data sharing
> | standpoint.  Empty classes contain no data to be shared, ergo are
> | not interesting.

I don't understand this point.

What about source compatibility?

My point was that I would like a header file that looks like:

extern "C" {
  struct S {};
  ...
}

to have the same meaning in both languages; that's not possible if S has
size zero in C.  Gaby's example is one exmaple; sizeof(S) is of course
another.  Another is structs that include S as a data member, etc., etc.

The current behavior means that verifying that a C structure will have
the same layout in C++ requires a recursive walk of the entire data
structure.  Consider, for example:

  struct S {};
  struct T { struct S s1; struct S s2; };

In C, GCC gives T size zero; both size zero S structures at located at
offset zero.  In C++, the language requires that T have size at least
two.  There might be actual data mixed in with the empty stuff; in that
case, the offsets of the actual data will be different in C and C++.

How am I, as a C or C++ programmer writing header files to be used in both
languages supposed to deal with this issue?

What if some other library on the system (e.g., glibc) ends up with a
size zero structure in its headers?  Then, I cannot even know that I
have this problem without recursively examining all the types used in
my program?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C ABI: struct/union inconsistency

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

[...]

| > That means we lose C/C++ compatibility even for a type which is in
| > the common subset of both languages.
| 
| Compatibility between C and C++ is interesting from a data sharing
| standpoint.  Empty classes contain no data to be shared, ergo are
| not interesting.

The point is that do we really want

     struct S s[190];

     assert (s != s + 189);

have different behaviour in that common subset.
I think we should retain objects' identities the same in that common
subset. 

-- Gaby

Re: C ABI: struct/union inconsistency

[Richard Henderson]

On Fri, Sep 27, 2002 at 10:21:59AM -0700, Mark Mitchell wrote:
> I must say that I'm concerned about the fact that things like:
> 
>  struct S s[3];
> 
>  ... sizeof (s) / sizeof (S) ...
> 
> won't work, and that s[0] and s[1] have the same address.

Yeah, well... caveat programmer.

We could perhaps prevent zero sized structures from being put into
arrays.  We should look to see if that ever happens in existing code
first though.

> That means we lose C/C++ compatibility even for a type which is in
> the common subset of both languages.

Compatibility between C and C++ is interesting from a data sharing
standpoint.  Empty classes contain no data to be shared, ergo are
not interesting.

> Perhaps we should offer a switch and/or attribute to control this
> behavior?

I don't think that's worth the bother.

> That sounds, then, like an agreement to change the alignment of the
> union example to match the struct example?

Yes.


r~

Re: C ABI: struct/union inconsistency

[Mark Mitchell]

--On Friday, September 27, 2002 10:06:16 AM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Wed, Sep 25, 2002 at 04:58:11PM -0700, Mark Mitchell wrote:
>> I also do not know if some piece of code in the Linux
>> kernel is going to depend on the current behavior; we might want to
>> have a switch for the old behavior.
>
> I think that we should leave structures with no members whatsoever
> alone.  I think that as shown by the linux kernel code, this is a
> useful feature.

We should at least document this behavior.  It is, I believe, different
from what any other compiler does.

I must say that I'm concerned about the fact that things like:

  struct S s[3];

  ... sizeof (s) / sizeof (S) ...

won't work, and that s[0] and s[1] have the same address.

At least in C++, that's a major violation of the object model; the
standard basically defines object identity as the pair of the object's
type and the object's address.  (I don't know if the C standard really
defines this concept.)

Finally, the C++ ABI requires that PODs have the same layout as the
equivalent C structures, but, on the other hand, the C++ standard
requires that empty structures have size one.

That means we lose C/C++ compatibility even for a type which is in
the common subset of both languages.

Perhaps we should offer a switch and/or attribute to control this
behavior?

> I don't care what we do with structures with no named members, but
> some unnamed members.  As Joseph points out, this is undefined in C.
> We might as well match whatever the C++ language requires, simply
> for consistency.

That sounds, then, like an agreement to change the alignment of the
union example to match the struct example?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C ABI: struct/union inconsistency

[Richard Henderson]

On Wed, Sep 25, 2002 at 04:58:11PM -0700, Mark Mitchell wrote:
> I also do not know if some piece of code in the Linux
> kernel is going to depend on the current behavior; we might want to
> have a switch for the old behavior.

I think that we should leave structures with no members whatsoever
alone.  I think that as shown by the linux kernel code, this is a
useful feature.

I don't care what we do with structures with no named members, but
some unnamed members.  As Joseph points out, this is undefined in C.
We might as well match whatever the C++ language requires, simply
for consistency.


r~

Re: C ABI: struct/union inconsistency

[Joseph S. Myers]

On Wed, 25 Sep 2002, Mark Mitchell wrote:

> Accepting empty structures in C is an extension, but structures like S
> (i.e., with a single zero-width bitfield) are part of the language.

They are not; a structure with no named members is undefined behavior
(6.7.2.1#7), and a zero-width bit-field may not be named (6.7.2.1#3).

> might be.  I also do not know if some piece of code in the Linux
> kernel is going to depend on the current behavior; we might want to
> have a switch for the old behavior.

Linux uses size 0 empty structures for efficiency (types that only need be
nonempty in SMP kernels), but only with sufficiently recent GCC; with
older GCC nonempty dummy structures are used because of compiler bugs.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

C ABI: struct/union inconsistency

[Mark Mitchell]

On x86 (and other PCC_BITFIELD_TYPE_MATTERS machines), this program:

  #include <stdio.h>

  struct S { long : 0; };
  union U { long : 0; };

  int main () {
    printf ("Alignment of S: %d\n", __alignof__(struct S));
    printf ("Alignment of U: %d\n", __alignof__(union U));
    printf ("Size of S: %d\n", sizeof(struct S));
    printf ("Size of U: %d\n", sizeof(union U));
  }

gives suprising output:

 Alignment of S: 1
 Alignment of U: 4
 Size of S: 0
 Size of U: 0

According to the doumentation for PCC_BITFIELD_TYPE_MATTERS:

     The behavior is that the type written for a bitfield (`int',
     `short', or other integer type) imposes an alignment for the
     entire structure, as if the structure really did contain an
     ordinary field of that type.

That would suggest that both S and U should have 4-byte alignment.

Note further that the psABI for x86 says explicitly that an unnamed
bitfield does *not* affect the alignment of the structure, although it
does affect the alignment of the next field.

So, as far as I can tell, we are both inconsistent with our own
documentation (in that we do not align S) and wrong as far as the
psABI is concerned (in that we do align U).

Lovely.

The size is another issue.  Giving empty sturctures size zero is
rather unfortunate; note that we also give an array of type "S[3]"
where "S" is an empty class size 0. That's distinctly odd; we have
all the array elements at the same location.

Accepting empty structures in C is an extension, but structures like S
(i.e., with a single zero-width bitfield) are part of the language.

In C++, empty structures are allowed, but are explicitly required to
have non-zero size.

I think we should adopt this same rule in C.  I cannot find anything
in the C99 standard that requires types to have a non-zero size, but
there are suggestions of that -- such as a note mentioning the:

  sizeof (array) / sizeof (array[0])

trick, which clearly does not work if array[0] has zero size.

I think we ought to:

(a) Change our docs to make clear that PCC_BITFIELD_TYPE_MATTERS does
    not cause unnamed bitfields to align structures.

(b) Fix our code so that alignment for unions is handled like
    structures.  This is an ABI change, but one that will affect 
    almost zero programs -- putting an unnamed bitfield in a union
    is something only someone writing ABI tests would try.

(c) Make all structures/unions have size at least one in GCC.

The combination of (a) and (b) will make our code consistent with the
docs and will make us match the psABI.  

The addition of (c) will avoid all kinds of weirdness for anyone who
actually makes empty structures, and will make C and C++ consistent.
I do not know if (c) is actually required by the C standard, but it
might be.  I also do not know if some piece of code in the Linux
kernel is going to depend on the current behavior; we might want to
have a switch for the old behavior.

What do others think we ought to do about this?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com