Russ Allbery <ea...@eyrie.org>: > 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 uses it will automatically learn about some problems that they currently don't know about. Typically it's more painful to turn on warning flags later instead of the beginning. I think it's helpful for production builds, too. Production builds are often created by people who aren't the original developers. If there are a lot of warnings, that's a hint to the production builder that he might 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 _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
