On Thu, Jun 06, 2002 at 11:28:52AM -0700, Greg Stein wrote:
> > Just -pedantic -Wno-long-long will do. You don't want to specify
> > -ansi (or -std=anything); it is liable to cause the system headers to
> > limit the set of provided declarations, which in turn will cause APR
> > to be confused. All the useful standard-compliance warnings (that you
> > don't get already with -Wall) come with -pedantic.
>
> Just to point out: Zack is *very* intimate with GCC. I say we take his
> advice :-)
Well, as long as you're listening to me :-) you might want to try out
a few more warning switches:
-Wwrite-strings gives all string constants the type 'const char *' (as
they do in C++). This is liable to force you to add const qualifiers
all over the program, but will expose bugs that are otherwise pretty
much unfindable.
-Wstrict-prototypes makes sure every function declaration is a
prototype; -Wmissing-prototypes insists on a separate prototype for
every function definition. The combination of the two effectively
enforces a style where all functions are prototyped either at the top
of the file or in a header. Some people don't like this, but it's the
best way we've found to flush out type mismatches across files. (You
do have to watch for external functions being declared in the source
file instead of headers. I suppose we now have enough information to
warn about that, too... hmm...)
-Wcast-qual will tell you if you ever cast away const or volatile.
This is not on by default because some people (including me) like to
have write-once structures in malloc space, referred to after creation
through const pointers, which eventually have to get freed -- and the
call to free() must cast away the const. (I'd be delighted to hear a
better way to approach this one.)
-W turns on a grab bag of warnings that have moderate to high
false-positive rates. Depending on your coding style, it may
be more trouble than it's worth. I don't know Subversion
style well enough to say.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 8 00:50:13 2002