Thanks for the info. What I'll probably do is file a bug and reply to this thread and the other one when I do.
On Thu, Feb 25, 2016, 2:50 PM Joseph Myers <jos...@codesourcery.com> wrote: > > On Wed, 24 Feb 2016, Wink Saville wrote: > > > Further more things like printing of "big" bit fields such as > > unsigned long long int b:33 doesn't issue any warnings with -Wall on clang > > Of course, printing such a bit-field with %llu etc. isn't fully portable > even with the C++ semantics for bit-field types. With the C++ semantics, > if int is 34 bits or more then it gets promoted to int; otherwise, if > unsigned int is 33 bits or more then it gets promoted to unsigned int. So > as with many cases of using variadic functions, you need to include a cast > to get the desired types. It just so happens it's hard for warnings to > tell how portable you want the code to be, or to tell whether an > unportable format for a type was e.g. autoconf-detected to be correct. > > > If someone were to supply a patch that changed the behavior to match > > what clang and apparently other compilers are doing, would you be likely > > to accept it? > > Not without a clear direction from WG14 to require the C++ rules (in which > case conditionals on the C standard version would be appropriate, given > the previous direction from the C90 DRs). You'd need to track the > declared type for each bit-field alongside the reduced-width type, apply > C++-style promotions and conversions to the declared type for relevant > rvalue uses, and handle the types appropriately in _Generic and typeof - > other changes could be needed if e.g. conversion from floating-point to > bit-fields were defined to convert to the declared type and then convert > from that to the bit-field. (A narrower direction only defining types in > _Generic might still require tracking declared types but not require so > many other changes.) > > -- > Joseph S. Myers > jos...@codesourcery.com
