------- 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
