proposal: add -Werror-implicit-function-declaration to the default optflags

Hans de Goede j.w.r.degoede at hhs.nl
Tue Mar 25 08:46:30 UTC 2008


Dave Jones wrote:
> On Mon, Mar 24, 2008 at 10:03:30PM +0100, Hans de Goede wrote:
>  > Hi all,
>  > 
>  > This is a new thread spawning from the "3.6% of heads up: Please correct your 
>  > #includes or optflags use" thread.
>  > 
>  > I would like to propose to add "-Werror-implicit-function-declaration" to the 
>  > default optflags. Why? Because missing prototypes can cause all sorts of problems:
>  > 
>  > Anything (any function) that returns a pointer, will be a problem when compiled 
>  > on 64 bit without a prototype, as the compiler will assume the return type is 
>  > an int, and then cast that to a pointer as needed.
>  > 
>  > Anything returning a float / double will be a problem regardless of 32/64 bits 
>  > as only 32 bits of the returned floating point number will be taken and 
>  > interpreted as an int (and then cast back to a float / double if used as such).
>  > 
>  > Any function called with arguments of different type then expected (for example 
>  > a float, where the function expects an int or visa versa) will have the same 
>  > problem.
>  > 
>  > Which is why I say: fix them all.
> 
> I agree with the sentiment, but I don't think the timing is right.
> This really needs to be done right after a release, so we've got plenty of
> time to fix some of them.  It isn't always as simple as "just add a #include".
> I looked into some of the warnings coming from the X server a month or so ago,
> and there's what appears to be some pretty icky layering violations.
> 
> Going from "this really shouldn't be doing that" to "this doesn't build any more"
> and adding a ton of work to peoples plates right before we ship a release
> sounds like a guaranteed way to make sure we miss the release date.
> 

Agreed,

So this would be a good change to make directly after rawhide opens for F-10, 
any people objecting? or shall I file an RFE against rpm?

Regards,

Hans




More information about the fedora-devel-list mailing list