Re: Testing for unknown flags in different compilers

[David A. Wheeler]

Bob Friesenhahn <address@hidden> stated:
> I don't think that it is a particularly good idea to enable any 
> warning options by default in a package unless the warnings are likely 
> to indicate that the code the developer should have already perfected 
> is somehow faulty (e.g. unexpected interface definition or missing 
> prototype) on the system it is being built on.
> 
> Usually only the developers of a package are interested in seeing and 
> fixing warnings.  Warnings are only a cause for concern (usually undue 
> concern) for others.

I strongly disagree.

I think many *end-users* want to know about warnings too.  By end-users, I mean 
people who are NOT developers but are compiling the code, including distro 
packagers.  If I compile software and I can see that it triggers LOTS of 
compile-time warnings, that’s a big hint on how much care the developers are 
taking in the quality of their software.  It’s not a perfect correlation; good 
software can sometimes trigger many errors, and bad software can be 
warning-free.  Still, when you’re looking at new-to-you software, these 
warnings are a data point worth knowing.

This isn't just speculation.  I just recently downloaded a new-to-me program 
(in this case, Metamath), and to roughly measure its quality, I simply turned 
on gcc warning flags (in my case "-Wall -Wextra") to see how clean it was when 
I compiled it.  It turned out there were *NO* warnings.  Sure, that doesn’t 
mean the software is perfect, but that *did* suggest to me a quality of care.

I think *many* people agree that warnings can be useful.  E.G., Keith Packard 
recently worked to eliminate the warnings from X windows 
(http://keithp.com/blogs/xserver-warnings/). He said, “One of the developers 
was looking over my shoulder while the X server was building and casually 
commented on the number of warnings generated by the compiler…. I felt like I 
had invited someone into my house without cleaning for months — embarrassed and 
ashamed that we’d let the code devolve into this state.”
 
But how can we make sure that developers are more likely to see or heed these 
warnings?  Well, if they're on by default, developers are more likely to see 
them of course.   But it's important that *users* also see them, if for no 
other reason than that developers will know that *users* who compile the 
program will see the same errors (and thus have an incentive to fix them).  And 
Dale Visser is also working on a way to portably *control* these flags for 
cases where a particular flag isn't appropriate (or should be added), so 
there's no problem if the default is not so great for your specific program.

I think it is NOT a good idea for a developer to see warning messages in his 
builds, but then suppress them for end-user builds. Better to suppress them 
with good reason for all builds, if they are not relevant!  Or if not, at least 
document why certain warnings are not being "fixed"... and they're way more 
likely to be fixed or documented if the users can easily see them.

--- David A. Wheeler