Re: !!, what is it?

Tim Woodall <devnull@xxxxxxxxxxxxx> writes:

> On Tue, 13 Sep 2005 09:12:42 +0200,
> Michael Mair <Michael.Mair@xxxxxxxxxxxxxxx> wrote:
[snip]
> > This was not my question. I am well aware of s-m and 1s complement,
> > my question more or less is whether it is possible that a signed
> > int bitfield could be treated as if it was an unsigned int
> > bitfield?
> >
> No. (IMO) 6.7.2.1
>
> 9 A bit-field is interpreted as a signed or unsigned integer type ...
>
> and then footnote 104) paraphrased - if the type specifier is int it is
> implementation defined whether the bitfield is signed or unsigned
>
> Which implies to me that signed int -> signed, unsigned int -> unsigned
> and int goes to one or the other.

It is possible for a signed int bitfield to behave as though
it holds an unsigned int bitfield value.

On a one-bit bitfield, for example, an implementation could
define 0 as "zero" and 1 as "trap representation". Storing
any non-zero value into the bitfield would result in a trap
representation, which can do anything because of undefined
behavior. In particular, storing a 1 could later result in
a 1 being produced.

A multi-bit bitfield could have all "negative values" be
trap representations. Sort of weird, but it's allowed. At
least, I haven't found any language in the Standard that
disallows it. The particular case of a non-zero being
stored in a 1-bit bitfield is explicitly allowed (in section
6.2.6.2 p2); it does at least have to be explicitly
identified by the implementation.

Because of the wonders of undefined behavior, it's also
possible to mix and match. For example:

struct {
signed int a:1;
signed int b:1;
} bits;

bits.a = 1;
bits.b = -1;
printf( "a: %d b: %d\n", bits.a, bits.b );

could very well print "a: 1 b: -1" as its output. Something
like this might happen if a compiler did some dataflow
analysis and determined that the 'a' field is used to hold
1's and 0's and the 'b' field is used to hold 0's and -1's.
Once some evaluation results in a trap representation being
stored, any behavior is possible -- it doesn't have to be
consistent from variable to variable.
.

Relevant Pages

  • Re: Checking endianess in compile time
    ... > unsigned int tffca: 1; ... > Is there a way to check if the compiler considers bitfield ten to be ... I would like to have the compiler give an error message ( ... Since you care about the exact representation of the bitfield, ...
    (comp.lang.c)
  • Re: GCC bitfield packing
    ... Will the base type of bitfield declaration affect the ... In this example, it uses "unsigned int a:1", what will happen if I ... change it to "unsigned char a:1". ... specify the minimum storage for a bitfield? ...
    (comp.std.c)
  • Re: Question about bit-fields and portability
    ... unsigned int val1: 1; ... How can such a bit-field struct be used in a non portable way? ... network) and then try to restore it on a platform with different ... or that a plain int bitfield of 1 bit can have two ...
    (comp.lang.c)
  • Re: [PATCH] hda_intel.c - Consolidate bitfields
    ... added a new bitfield not adjacent to other ... bitfields in the same struct. ... Applied to sound git tree now. ... unsigned int running:1; ...
    (Linux-Kernel)