make warnings in nnrpd

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> I don't suppose we can put "compile without warnings" on the todo list
> for 2.4, but it'd be nice.

We're pretty close.  I can try to clean up some more of the innfeed
warnings.  There are a bunch in the ovdb code, many of which are
stylistic, and I'm still not sure what's up with all the warnings about
different alignmnent that the IPv6 code kicks out.

> I cleaned up the last few for nnrpd today; all that's left is:

> - warnings from system headers (mostly gcc extensions, zero-length 
>   structs, perl stuff, and TLS stuff)

A brand-new gcc should hopefully help with this some, since it now
suppresses warnings in system headers.  The Perl stuff is hard to fix
completely, though, since Perl's headers just aren't at all warning-free.

One thing that may help, though, is to figure out how to include the Perl
headers with -isystem instead of -I when looking for warnings, which with
a recent gcc (probably 3.2 or so) will suppress warnings from those
headers as is done with system headers.

> - comments about %m in syslog() calls

I think this is only in innfeed, right?  I haven't fixed this yet because
it's a pain to figure out what's going on with that code since all of the
output formats are all collected together in one header file.  Ideally,
all those preprocessor symbols should be expanded out in the files where
they occur; I don't think we're gaining anything by having them collected
in one place.  We also want to use the inn/messages.h functions; once
we're using sysdie, syswarn, and sysnotice as appropriate rather than
syslog calls, we can drop the %m.

> - the warning about mktemp in ICCopen that we get from linking to libinn

Bleh.  I'm not sure the best solution to that, as this is a case where
mkstemp doesn't really do what we want and there are no security
implications for doing what we're currently doing.

> - some casts from const char* to char* for IOv usage, variable 
>   initialization with string constants, or some SASL calls

I think that we'll eventually need to drop -Wcast-qual, since these are
correct and are just noise.

Except for the ton of them in perm.c, which are because the interface to
the old configuration parser is broken.  That will all be fixed when we
switch over to the new parser.

> - a few assignments from const char* to char* within HDR_SET in post.c,
>   that I could probably clean up if I thought harder

This would be good to look at when you (or someone) gets a chance.

> - crazy stuff from the Perl macros

This we can't do a lot about, besides isolate it to one file.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.