This is the mail archive of the
mailing list for the GCC project.
Feature request - error for implicit int return in pointer context
- From: Pavel Roskin <proski at gnu dot org>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 14 Aug 2006 16:05:34 -0400
- Subject: Feature request - error for implicit int return in pointer context
I've been bitten by a bug in some software I use every day (I didn't
write it, but it's a part of. When compiling it with gcc-4.1.1, I'm
getting tons of warnings, and the bug was triggering a warning too, I
think it should have been an error.
It's the case where the return value of an undeclared function is used
as a pointer, e.g:
void *ret = foo();
$ gcc -c -Wall hello.c
hello.c: In function 'fun':
hello.c:3: warning: implicit declaration of function 'foo'
hello.c:3: warning: initialization makes pointer from integer without a
What happens here is that gcc implies that the function returns an
integer, and then is proven to be wrong, because the value is used as a
I read somewhere that gcc issues warnings rather than errors when it
understands what the code means. I believe it's the case where it
doesn't. Standard compliance requires gcc to interpret the return
result in a way that doesn't correspond to the actual context of the
This code is virtually guaranteed to break on 64 bit platforms (i.e.
when pointers and integers have a different size).
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