[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_*/AM_* macros for options

From: David A. Wheeler
Subject: Re: AC_*/AM_* macros for options
Date: Thu, 31 Oct 2013 21:05:26 -0400 (EDT)

Russ Allbery <address@hidden>:
> The last time I turned [-Wconversion] on for a project, the only warnings it 
> produced
> were either complaints about code that was provably fine without changes
> or bogus warnings about ntohs.  I fixed the ones that were fine anyway,
> just because I'm anal like that, and then turned it off because I always
> use -Werror when doing development builds and am not willing to turn on
> warnings I can't suppress in every circumstance...
>... But I agree
> with Paul's point in general: it's a warning that doesn't work well with
> code that's dealing with corner cases, like types that could be signed on
> some hosts and unsigned on others.

Clearly some flags shouldn't be turned on by default, and if some are
turned on by default, there needs to be clear and simple ways to control them.
Completely agree.

> I'm currently only using warning flags for developer builds.  I'm still
> making up my mind on whether enabling them for production builds would
> find more problems than it would cause.

If warning flags are turned on by default by autoconf, then any developer who 
it will automatically learn about some problems that they currently don't know 
Typically it's more painful to turn on warning flags later instead of the 

I think it's helpful for production builds, too.
Production builds are often created by people who aren't the original 
If there are a lot of warnings, that's a hint to the production builder that he 
want to check further.  Maybe they're all legit... or maybe the original 
developer keeps
making bone-headed mistakes.  Warnings tell people that something
might not be okay, and where to look to find out more.

--- David A. Wheeler

reply via email to

[Prev in Thread] Current Thread [Next in Thread]