On Mon, 2006-08-14 at 22:44 +0200, Andreas Schwab wrote:
> Pavel Roskin <[EMAIL PROTECTED]> writes:
>
> > I don't know much about gcc implementation, but if it's not hard to
> > check the context of the function call (or, alternatively, the
> > provenance of the integer that is about to be cast to a pointer), I'll
> > appreciate if this case is promoted to an error, and least for 64-bit
> > targets.
>
> Try -Werror-implicit-function-declaration. Not the same, but pretty
> close.
Thanks! I know. In fact, I'm using at least "-Wall -Werror" for my
code and for the code I'm working with, so it's implied. I'm talking
about code that I have never seen until the binary did a poo-poo on my
machine.
Sure, I can petition Fedora, Novell, Debian and others to use
-Werror-implicit-function-declaration, but I don't think I'll have
convincing arguments.
There is lots of old code in existence that lacks some declarations and
that would work if compiled for a 64-bit system. This sloppiness can be
tolerated to a degree.
But if an undeclared function returns a pointer, this will break the
code almost definitely. That's why I want gcc to reject this code.
Then it won't be me reporting brokenness to e.g. Fedora after 2 days of
setting up the build environment and chasing unrelated issues in the
libraries. It will be Fedora fixing this crap before it comes to the
users.
If the prototypes disappear, most code that worked would still work the
same way. In fact, -Wconversion will find the exceptions provided that
the prototypes are present. The compiler would not convert pointer
arguments to int. Pointers will be sent as pointers.
But the return value will be converted to int and thus broken. Hence my
plea: if you can detect it, please reject it.
Another approach would be to assume functions to return a pointer in the
pointer context. I think it would be against standards, therefore I'm
not asking for it. Also, this approach could lead to silently
miscompiled code if different files use the function is different
contexts, e.g.:
file1.c:
if (!foo()) /* assuming int, using 32 bits */
return;
file2.c:
void *ptr = foo(); /* assuming pointer, using 64 bits */
Without such "smartness", file2.c would fail to compile, forcing user to
add foo() to the headers thus fixing file1.c. Thus, if the function is
ever called in the definitely pointer context, it would trigger an
error.
--
Regards,
Pavel Roskin
