This is the mail archive of the
mailing list for the GCC project.
Re: Feature request - error for implicit int return in pointer context
- From: Pavel Roskin <proski at gnu dot org>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 14 Aug 2006 20:38:38 -0400
- Subject: Re: Feature request - error for implicit int return in pointer context
- References: <1155585934.10400.24.camel@dv> <firstname.lastname@example.org>
On Mon, 2006-08-14 at 22:44 +0200, Andreas Schwab wrote:
> Pavel Roskin <email@example.com> 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
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
Sure, I can petition Fedora, Novell, Debian and others to use
-Werror-implicit-function-declaration, but I don't think I'll have
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
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
if (!foo()) /* assuming int, using 32 bits */
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