Another glibc fixincl-hack

Bruce Korb
Sat Dec 2 21:38:00 GMT 2006

Zack Weinberg wrote:
>>  s/ calloc (1, 1)/ calloc ((size_t)1, (size_t)1)/
> This really shouldn't be necessary; right above you have an #include of
> stdlib.h, which should make a prototype available for calloc, which should
> ensure the proper conversions occur with no need for explicit casts.  Could
> you supply a minimal test case and preprocessed source for it?

So, perhaps the warnings are amped up too high:

$ gcc -std=gnu99 -O2 -Wall -Werror -Wcast-align -Wconversion -Wmissing-prototypes \
 -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing \
 -c str.c
str.c: In function `foo':
str.c:4: warning: passing arg 1 of `calloc' with different width due to prototype
str.c:4: warning: passing arg 2 of `calloc' with different width due to prototype

The source:

> > #include <string.h>
> > char * foo(void) ;
> > char * foo(void) {
> > char * pz = strdup("the quick brown fox");
> > return pz; }

If I remove the "-O2" optimization, the warning also goes away.
It would seem reasonable that one of the following is true:

* strdup can easily ensure that the arguments match

* GCC should not bother with argument promotion warnings:
> `-Wconversion'
>      Warn if a prototype causes a type conversion that is different
>      from what would happen to the same argument in the absence of a
>      prototype.  This includes conversions of fixed point to floating
>      and vice versa, and conversions changing the width or signedness
>      of a fixed point argument except when the same as the default
>      promotion.
>      Also, warn if a negative integer constant expression is implicitly
>      converted to an unsigned type.  For example, warn about the
>      assignment `x = -1' if `x' is unsigned.  But do not warn about
>      explicit casts like `(unsigned) -1'.
  Perhaps separate out a -Wsigned-conversion ??  That's the main interest.
  I'd use that instead of this ``-Wconversion'' thing.

But one or the other.  Promoting an int to a size_t should not be so
troublesome.  :)

Thanks - Bruce

More information about the Gcc-patches mailing list