<div dir="ltr">Thanks for the great explanation, I agree with this advice. I'm going to investigate writing a new patch to do this.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 18, 2016 at 1:59 PM, Arthur O'Dwyer <span dir="ltr"><<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Thu, Nov 17, 2016 at 2:14 PM, Sasha Bermeister <span dir="ltr"><<a href="mailto:sashab@chromium.org" target="_blank">sashab@chromium.org</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Although I agree with your philosophical discussion and suggestions, the reality is that MSVC's behavior is not a bug and compilers are free to interpret enum bitfields with no explicit underlying type in any way they want (see spec reference in GCC bug link), with a signed interpretation being a valid one. I'd say it's undefined behavior in C/C++ to store an enum in a bitfield without specifying an underlying type, since the compiler is free to interpret this bitfield in any way it wants -- in general, if you haven't specified an underlying type you should probably be warned when trying to store it in a bitfield because the compiler may not do what you expect.</div></blockquote><div><br></div></span><div>Incorrect. The following program has perfectly well defined behavior:</div><div><br></div><div>enum E { e = 0 };</div><div>struct S { E bf : 4; } s;</div><div>int main() { <a href="http://s.bf" target="_blank">s.bf</a> = e; }</div><div><br></div><div>No compiler in the world should produce a warning on the above program.</div><div><br></div><div>Also, once you've got a struct type containing an offending bit-field, <i>any</i> use of that bit-field is subject to the implementation-defined behavior you noticed on MSVC. It's not just limited to assignment-expressions of constants. That's why it's important to produce a warning on the <i>declaration</i> of the bit-field, not on each subsequent expression that refers to that bit-field.<br></div><div><br></div><div><div>enum E2 { e = 0, f = 1, g = 2, h = 3 };</div><div>struct S2 { E2 bf : 2; } s;  // this line should trigger a diagnostic</div><div>int main() { <a href="http://s.bf" target="_blank">s.bf</a> = e; }</div></div><div><br></div><div>Also, the current patch's diagnostic wording suggests to "consider giving the enum E an unsigned underlying type", which would be very bad advice in this situation (because it only works in C++11, and because it triggers a GCC bug, and because it has non-local effects on the program's semantics). The correct advice is to "consider giving the bit-field bf a width of 3 bits instead of 2."</div><div><br></div><div>HTH,</div><div>–Arthur</div></div></div></div>
</blockquote></div><br></div>