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