[PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 16 18:43:41 PST 2016


On 16 November 2016 at 18:38, Nico Weber via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> I'm a bit surprised that this landed, given that gcc bug. I can see the
> motivation for the gcc bug: If you say your enum is going to need
> underlying 8 bits, then warning that your bitfield where you store it is
> smaller _is_ surprising.
>

Yeah, suggesting adding an underlying type to the enum to solve this
problem seems like a bad idea, since that fundamentally changes the nature
of the enum -- typically allowing it to store a lot more values, and making
putting it in a bitfield a bad idea.

I'm not sure if landing this while gcc still behaves the way it does is a
> good idea :-(
>
> On Thu, Nov 10, 2016 at 9:38 PM, Mehdi AMINI <mehdi.amini at apple.com>
> wrote:
>
>> mehdi_amini added a comment.
>>
>> > So when this modification tells the developer to add 'unsigned' to
>> their enum, they are subsequently causing a warning to occur in GCC.
>> >
>> > I have commented on the bug on GCC for this (
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242#c28), but it looks
>> unlikely to be fixed.
>> >
>> > Should we go ahead and add this warning when following its instructions
>> will cause a warning in the GCC compiler? Even though GCC is at fault here,
>> I'm not sure what the right thing is to do.
>>
>> GCC seems to agree that they should fix it:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 ; so I wouldn't
>> consider it a blocker.
>>
>> But I'm not using GCC either, and I don't know what is our usual policy,
>> so it'd be nice to have another opinion here.
>>
>>
>> https://reviews.llvm.org/D24289
>>
>>
>>
>>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161116/9cfc3cb0/attachment-0001.html>


More information about the cfe-commits mailing list