In article <3ssovf$8b3@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) says:
>If you mean that 'a' and 'b' each take up a full word, I would complain
>to the vendor.

To be specific the whole structure takes at least sizeof(int). Whereas the unsigned char
declared bitfields structure takes at least sizeof(char). If you mix the two types you get
which ever is larger (so sizeof(int)).

>That is really strange. The whole thing is implementation-defined, but
>the alignment should depend primarily on the number of bits, and bitfields
>less than 8 bits should be packed the same regardless of their
>declared type,

I agree, but apparently the vendor does not. (Big sigh)

>You can't expect anything. It is up to the compiler implementor,
>but it has to be documented. The size and alignment of all the
>built-in types vary among implemenations, as does the handling
>of bitfields. Type bool is not different in this regard.

I was afraid you would say that.

In article dia@scorpio.develop.bsis.com, Kimbal.Welch@bsis.com (Kimbal Welch) writes:
>> >That is really strange. The whole thing is implementation-defined, but
> >the alignment should depend primarily on the number of bits, and bitfields
> >less than 8 bits should be packed the same regardless of their
> >declared type,
>
> I agree, but apparently the vendor does not. (Big sigh)

It's probably not the vendor but SV ABI, which mandates the behavior you
are complaining about.  I agree completely with your evaluation of that
behavior.  As far as I can tell the SV ABI simply documents and mandates a
bug in the AT&T C compiler.


-Mike Ball-
SunSoft Developer Products

In article soj@scorpio.develop.bsis.com, Kimbal.Welch@bsis.com (Kimbal Welch) writes:
>
>So here's the problem. My compiler will allocate a whole integer to bitfields defined as
>'unsigned int' as in:
>
>struct {
> unsigned int a:1;
> unsigned int b:1;
> }

If you mean that 'a' and 'b' each take up a full word, I would complain
to the vendor. It is allowed (I believe) for the compiler to do that,
but kind of defeats the purpose of bitfields.
>
>but it will allocate only a character when a bit field is defined as:
>
>struct {
> unsigned char a:1;
> unsigned char b:1;
>       }

That is really strange. The whole thing is implementation-defined, but
the alignment should depend primarily on the number of bits, and bitfields
less than 8 bits should be packed the same regardless of their
declared type, IMHO. This is nevertheless only a "quality of implementation"
issue, not a deviation from the standard.

>
>So if I create a bit field using bool:
>
>struct {
> bool a:1;
> bool b:1;
> }
>
>can I expect it to allocate a sizeof(int) or a sizeof(char),

You can't expect anything. It is up to the compiler implementor,
but it has to be documented.

The size and alignment of all the built-in types vary among implemenations,
as does the handling of bitfields. Type bool is not different in this regard.
---
Steve Clamage, stephen.clamage@eng.sun.com

In article <3sppjj$jls@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) says:
>It is implementation-defined, and in particular is not required to be 1.
>On the other hand, a value of type bool can be stored in any object of
>integral type, and in any bitfield, even a 1-bit bitfield.
>
>That is, only one bit is required to store a 'true' or 'false' value, but
>an object of type bool could be any size. So if it matters, be sure to
>use 'sizeof' to find the size of a bool.

>Rob Sartin Writes:
>It seems to be unspecified (or perhaps implementation-defined). It does not appear
>to be safe for an application to assume it must be 1 (or sizeof(int)). One might
>infer that if sizeof(bool)<=sizeof(int) based on the integral promotion rules (bool
>has a promotion to int, not other promotions are listed).  It is specified that a bool can
>be used in any non-zero-length bit-field.

So here's the problem. My compiler will allocate a whole integer to bitfields defined as
'unsigned int' as in:

struct {
 unsigned int a:1;
 unsigned int b:1;
 }

but it will allocate only a character when a bit field is defined as:

struct {
 unsigned char a:1;
 unsigned char b:1;
       }

So if I create a bit field using bool:

struct {
 bool a:1;
 bool b:1;
 }

can I expect it to allocate a sizeof(int) or a sizeof(char), or is it a completely random
selection dependant on the compiler manufacturer. If this is true then I can't write out
my 'bool' values and expect to read them in under different compiler implementations.

Yes, I know this problem is common to int, long, etc...; but why make it worse.

What is the proposed storage size of a bool type?

In article hpg@scorpio.develop.bsis.com, Kimbal.Welch@bsis.com (Kimbal Welch) writes:
>What is the proposed storage size of a bool type?

It is implementation-defined, and in particular is not required to be 1.
On the other hand, a value of type bool can be stored in any object of
integral type, and in any bitfield, even a 1-bit bitfield.

That is, only one bit is required to store a 'true' or 'false' value, but
an object of type bool could be any size. So if it matters, be sure to
use 'sizeof' to find the size of a bool.
---
Steve Clamage, stephen.clamage@eng.sun.com