[Bug c/22421] problems with -Wformat and bit-fields

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joseph at codesourcery dot com  2005-07-12 02:03 -------
Subject: Re:  New: problems with -Wformat and bit-fields

On Tue, 12 Jul 2005, wilson at gcc dot gnu dot org wrote:

> This problem showed up compiling the IA-64 linux kernel with gcc-4.0.1.  There
> was an unexpected printf format warnings for a 32-bit bit-field.  The same
> problem can be reproduced on any LP64 machine, such as x86_64-linux.

The format issues are bug 21962, but this bug is more detailed.

> 1) What printf formats should be allowed to match for a bit-field?  Or do we
> want to force use of a cast?  I think the gcc-3.3.x behaviour is correct and
> desirable.

If the bit-field has rank above that of int, then we must require a cast.

> 2) The type checking code in check_format_types needs to be extended to handle
> bit-field types properly.

I don't think any format checking code should need changing for this if 
the code handling creating bit-field types, promotions and diagnostics is 
made correct.

> 3) The behaviour of c_common_signed_or_unsigned_type should be checked.  Is it
> OK to return a standard integral type when the input is a non-standard integral
> type?  If this is OK, then shouldn't we also do this when the signedness is the
> same?  It seems odd that this routine can return either a standard integral type
> or a non-standard integral type, depending on signedness.
> 4) We should check if we still want the special bit-field check in
> perform_integral_promotions.  This one I think we can defer indefinitely.

If 32-bit bit-field types are to be nonstandard types (i.e. extended 
integer types) then they have rank less than that of 32-bit int so should 
promote to int and be accepted for int formats.  Either there should be a 
special check to make nonstandard types the same width as int promote to 
int, or possibly simpler the standard type should be used for bit-fields 
in that case.  More generally it may make sense to use standard types for 
bit-fields which have the same width as a standard type.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22421