Rule 6.5 and unnamed 0-length bit field

[pkruk]

What about following case:

Code:

struct s {
    signed int : 0;        /* Is Rule 6.5 violated? */
  };

Rule 6.5 explicitly says that \"Bit fields of type signed int shall be at least 2 bits long.\" (or \"Bit fields of signed type shall be at least 2 bits long.\" in TC1).

This bit field is clearly smaller than 2 bits, but it serves other purpose than \"normal\" positive-size bit fields.

Should the code be changed to use \"unsigned int\" type (the rule would not apply), or is the 0-size bit field an exception to this rule?

[George Brown]

Hi pkruk,

Is there any reason for not using an unsigned int zero bit field?

I.e.

Code:

struct s {
   unsigned int : 0;      /* unnamed zero length bit field */
};

George

[pkruk]

Hello George,

no, I don't know any reason to use e.g. signed int zero bit field instead of unsigned.

But I don't see a reason to impose using unsigned int in this case - it provides no value, as far as I know.

The rule explains further that \"A signed bit field of 1 bit length is not useful.\". This seems to suggest that the rule is concerned about usefulness of the code - and signed int zero bit fields are still useful.

In fact, shouldn't all unnamed bit fields be excluded from the scope of Rules 6.5 and 6.5? Do they have any use other than padding? If not, their type should not matter in my opinion.

[George Brown]

Hi pkruk,

I guess it might be to do with the stability of the rules.

The current rule is \"don't use less than two\".

If the rule was changed to \"don't use exactly one\", then there would be 1) a discontinuity, and 2) a change.

Since unsigned int : 0 can be used, there is a fully capable alternative, so no need to change the rule.

The undefined behaviour relates to not using signed or unsigned int, regardless of its use for zero length padding, and therefore still holds.

As the rule is written, signed bit fields are used to store data.

George

[sparker]

I don't really see that zero-length bitfields are in the spirit of MISRA at all. Since the only point in a zero-length bit field is to attempt to force a particular packing it doesn't seem very compatible with the wording \"the packing together of short-length data to economise on storage is the only acceptable use of bit-fields envisaged in this document\" (MISRACV1 rule 111-113).

My personal position is that bit-fields are generally the wrong answer to any problem. That goes double for zero-length ones.

stephen