Using a enum type for a bitfield

The short question:

Does clang support using an enum as a type for a bit-field?

C11 (6.7.2.1 P 5):

A bit-field shall have a type that is a qualified or unqualified version
of _Bool, signed int, unsigned int, or some other implementation-defined
type.

GCC (at least the latest) supports it:

https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Structures-unions-enumeratio=>
ns-and-bit-fields-implementation.html

So I'm curious as to whether clang supports it. I did find this on
bugzilla:

https://llvm.org/bugs/show_bug.cgi?id=3D11272

I'm not sure how hard the documentation system is, but is it time to
create a section in the manual to answer questions like this as they pop
up?

In the absence of documentation, I need to assume that the
implementation does not support it, which would make it undefined
behavior (and then I get to drive that out of the code base).

If the implementation does (or will) support it, then it drops down on
my priority list (I've got much more egregious undefined behaviors to
worry about). :slight_smile:

- michael

Hi.

The short question:

Does clang support using an enum as a type for a bit-field?

C11 (6.7.2.1 P 5):

A bit-field shall have a type that is a qualified or unqualified version
of _Bool, signed int, unsigned int, or some other implementation-defined
type.

...

So I'm curious as to whether clang supports it. I did find this on
bugzilla:

https://llvm.org/bugs/show_bug.cgi?id=3D11272

LLVM Bugzilla says:

'3D11272' is not a valid bug number.

Csaba

Bug number would be 11272 - the text has been mime-encoded to replace the = with =3D (since mime uses = as a special character, and =3D is the escaped = sign). Obviously, some step on the way didn’t understand the encoding and left it as plain text without decoding it.

Hi,

Bug 11272 - document implementation-defined behavior says nothing about bit fields.

@Serge:

I think the point of bug 11272 is to actually document [directly or referring to some other documentation elsewhere] ALL of the clang implementation defined behaviour, which includes the behaviour with bitfields from enums (and I expect it is identical to gcc’s behaviour, but I don’t KNOW that this is the case).

Yes, that's a good summary. bug 11272 is the request for this type of documentation. In general I think more people will be looking for this type of documentation such that the can determine how using this implementation will effect them.

In the near term we need a direct answer as to whether clang supports implementation defined behavior under C11 6.7.2.1 P 5, specifically the use of enums as bit fields.

We're starting to run into some issues that are indicating that it may not be supported, which is fine but we need to know the intentions for this behavior.

I suppose that technically if the implementation does not define the behavior then the behavior is not supported/undefined. If it's going to be supported we'd like to avoid unnecessary code churn. On the flip side we could just go remove this behavior and we won't have to worry about it if we decide to use a different implementation.

- michael

Implemmentation defined behaviour that is not "defined" is not the same as
undefined behaviour. There is a distinct difference in that implementation
defined behaviour is supposed to "work" (do something reasonably
meaningful) or not compile, where UB is allowed to result in just about
anything [covering both "works as you expect" (whatever "expect" may
entail) and "crashes" or "fails to compile"].

Of course, the spec also states that IDB should be documented, so
technically, the clang compiler is not fulfilling the specifications in
this respect.

I suspect, however, that if you are seeing a behaviour where the code
compiles, but isn't behaving as you expect, it's quite possibly a compiler
bug, rather than "implementation is intended to behave this way".

If the compiler does not support this, I'd very much expect the compiler to
NOT accept the source code, so in that respect it's a bug either way. But
it probably requires a small test-case to show the problem behaviour.

Technically, every open source implementation is documenting its
implementation-defined behavior by definition: you can always look at
the source code to see what the definition of the behavior is. Nothing
states that the documentation must be spelled out in easy fashion for
the user. Obviously, we'd be happy to raise that bar a bit and have
more formal documentation were someone willing to provide it.

~Aaron

Yes. However if we start finding inconsistencies (bugs) in the implementation, we need to understand what the desired behavior is. If we can document that it is intended behavior is I can then start diving in and fixing the problems we're seeing. If it's not the intended behavior then I dive in and start fixing the inconsistencies in a different way.

The general feeling I'm getting is "it should be supported" so I'll start going down that path.

- michael

If the code compiles, then it's either a bug that it compiles when it's not
supported, or a bug that it's not working correctly... :wink:

And I'm fairly sure that, since GCC supports it, and Clang is intended to
be a GCC plugin-recplacement, it should work in Clang too.