[Top][All Lists]

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

Re: AC_*/AM_* macros for options

From: Russ Allbery
Subject: Re: AC_*/AM_* macros for options
Date: Wed, 30 Oct 2013 18:54:46 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Jeffrey Walton <address@hidden> writes:

> Perhaps I'm approaching this the wrong way (I probably don't have your
> experience with the platform). When Linux/Unix folks turn off
> -Wconversion, what do they use to find the bad conversions?

The last time I turned it 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.  (Sometimes I cheat and
use pragmas to turn them off for particular files, but I really hate doing
that, and I definitely don't want to do that for everything that uses

Now that the ntohs problem has finally been fixed, I'll probably try
turning it back on again, since for the most part my code doesn't deal
with issues like the time_t one that Paul cited, and I have a high
tolerance for tweaking code to avoid warning false positives.  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.

There are a lot of gcc warnings that are really only useful in specific

FWIW, my normal warning set is:

# A set of flags for warnings.  Add -O because gcc won't find some warnings
# without optimization turned on.  Desirable warnings that can't be turned
# on due to other problems:
#     -Wconversion (htons warnings)
# Last checked against gcc 4.7.2 (2013-04-22).  -D_FORTIFY_SOURCE=2 enables
# warn_unused_result attribute markings on glibc functions on Linux, which
# catches a few more issues.
WARNINGS = -g -O -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wendif-labels          \
        -Wformat=2 -Winit-self -Wswitch-enum -Wuninitialized -Wfloat-equal \
        -Wdeclaration-after-statement -Wshadow -Wpointer-arith             \
        -Wbad-function-cast -Wcast-align -Wwrite-strings                   \
        -Wjump-misses-init -Wlogical-op -Wstrict-prototypes                \
        -Wold-style-definition -Wmissing-prototypes -Wnormalized=nfc       \
        -Wpacked -Wredundant-decls -Wnested-externs -Winline -Wvla -Werror

For one piece of code that doesn't use Autoconf at all and is therefore
designed to be maximally portable with no probing, I add -ansi -pedantic.
I normally don't do that because it requires manually fiddling with
feature test macros and actually decreases portability in some situations.

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.

Obviously, -Werror is almost never appropriate for production builds
unless the developers control all the hosts on which it will be built, or
unless it's only turned on optionally.

Russ Allbery (address@hidden)              <>

reply via email to

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