> I'll check in a change to that effect.
Done.
I'd be tempted to turn on "-ansi" and/or "-pedantic, except that the GCC
man page says of "-ansi"
The preprocessor predefines a macro __STRICT_ANSI__
when you use the `-ansi' option. Some header files may
notice this macro and refrain from declaring certain
functions or defining certain macros that the ANSI
standard doesn't call for; this is to avoid interfering
with any programs that might use these names for other
things.
and Ethereal isn't a "strictly conforming program", given that it has to
use all sorts of UNIX and GTK+ and "libpcap" APIs not specified by ANSI
C, so keeping the name space ANSI-clean may cause problems.
The man page says of "-pedantic"
-pedantic
Issue all the warnings demanded by strict ANSI standard
C; reject all programs that use forbidden extensions.
Valid ANSI standard C programs should compile properly
with or without this option (though a rare few will re-
quire `-ansi'). However, without this option, certain
GNU extensions and traditional C features are supported
as well. With this option, they are rejected. There
is no reason to use this option; it exists only to
satisfy pedants.
`-pedantic' does not cause warning messages for use of
the alternate keywords whose names begin and end with
`__'. Pedantic warnings are also disabled in the ex-
pression that follows __extension__. However, only
system header files should use these escape routes; ap-
plication programs should avoid them.
so perhaps that'll catch GNU C extensions and flag them - except for the
few extensions we use safely, e.g. "__attribute__(format, ...)", used to
tell GCC 2.x that a program has a "printf"-like calling sequence, which
we use only if "__GNUC__" is defined and is equal to 2.
