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.

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

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