[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Re: Implicition declarations of functions and bugs

David Mosberger-Tang, le Fri 10 Mar 2006 17:06:22 -0700, a écrit :
> I'm inclined to treat this as a gcc-4 bug.

It is not.

> $ cat t.c
> char *
> foo (char *str)
> {
>   return strdup(str);
> }
> $ gcc-3.3 -c -g -O -Wall t.c
> t.c: In function `foo':
> t.c:4: warning: implicit declaration of function `strdup'
> t.c:4: warning: return makes pointer from integer without a cast

Because strdup() here gets an implicit
int strdup(int str)
declaration, hence the warnings.

> gcc-4.0 -c -g -O -Wall t.c
> t.c: In function 'foo':
> t.c:4: warning: implicit declaration of function 'strdup'
> t.c:4: warning: incompatible implicit declaration of built-in function 'strdup'

Same story, except that gcc has additionnal knowledge of which prototype
the strdup function should have: char *strdup(const char *str); . And
char * and int are not compatible types.

> The gcc-3.3 warnings makes perfect sense.  The gcc-4.0 warnings are
> useless.

gcc-4.0 warnings are actually just more precise: not only there is a
missing declaration, but gcc has strong conviction that the implicit
prototype is really wrong (strdup() should really take char * and return
char *, not int).

> There is no hint on how the "implicit declaration of built-in function
> `strdup'" is incompatible.

Implicit declarations are in the form
int foo(int bar, int baz, etc.)
and the built-in strdup function has
char *strdup(const char *str)
as prototype. This is incompatible. gcc could even say "int is
incompatible with char*", but I guess gcc people consider this as too

This is a warning and not an error, because using one's own strdup()
function (that would take ints) is perfectly legal. gcc-4.0 emits the
warning to let the programmer know that he should disambiguate this by
either #including the usual C header, or by giving the prototype of his
own strdup() function.

Anyway, such warnings deserve grepping, since they are evidence of a
potential binary break.


Reply to: