Andy queried why we aren't using the GCC option "-Wall". I've been compiling for a few weeks now with extra GCC warnings enabled, to see whether it will help with portability issues or just be a nuisance. I used these options:
-Wall -pedantic -Wpointer-arith "-Wall" is highly recommended, and means "all normally useful warnings". The author of the GCC manual says you would never want to use "-pedantic", but it seems to be just what we need in order to write portable code. I added "-Wpointer-arith" to my list because it seemed like a good idea, but I haven't researched the pros and cons. This is how I use them: GCCFLAGS="-Wall -pedantic -Wpointer-arith [... and my other favourite options ...]" CFLAGS="$GCCFLAGS" CXXFLAGS="$GCCFLAGS" ./configure I have looked through all of the warnings from SimGear, and there are very few. About half are annoyances and half genuine (in my opinion); I have made notes on them, below. In FlightGear itself, there are (naturally) more warnings, but most of them are "genuine". My conclusion is that these settings are useful, and that the gain is worth the pain of working around the non-useful warnings. I recommend putting these settings in CVS (in autogen.sh ?). - Julian ----------------------------------- Here are all of the warnings from SimGear (about a week old): Making all in xml In file included from xmltok.c:260: xmltok_impl.c: In function `normal_getAtts': xmltok_impl.c:1394: warning: `open' might be used uninitialized in this function In file included from xmltok.c:653: xmltok_impl.c: In function `little2_getAtts': xmltok_impl.c:1394: warning: `open' might be used uninitialized in this function In file included from xmltok.c:792: xmltok_impl.c: In function `big2_getAtts': xmltok_impl.c:1394: warning: `open' might be used uninitialized in this function ["open" is not actually used uninitialized, so this is an annoyance; we would have to give it an initialiser, even though it would be redundant.] Making all in misc props.cxx: In method `SGPropertyNode::hash_table::~hash_table()': props.cxx:1980: warning: comparison between signed and unsigned [This is mostly harmless but should be fixed (and can be fixed easily and correctly).] Making all in io In file included from lowlevel.cxx:28: lowlevel.hxx:40: warning: ANSI C++ does not support `long long' lowlevel.hxx:41: warning: ANSI C++ does not support `long long' lowlevel.hxx: In function `void sgEndianSwap(uint64 *)': lowlevel.hxx:151: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:152: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:153: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:154: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:155: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:156: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:157: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:158: warning: ANSI C++ forbids long long integer constants [Is there a more standard way to get a 64-bit integer, like "int64_t" in <stdint.h> of ANSI C'99? This warning only appears when "-pedantic" is used, and can be inhibited with -Wno-long-long. This bunch of warnings came out four times.] Making all in metar Dcdmetar.cpp: In function `int DcdMETAR(char *, Decoded_METAR *)': Dcdmetar.cpp:2252: warning: `enum DcdMETAR(char *, Decoded_METAR *)::METAR_obGroup SaveStartGroup' might be used uninitialized in this function Dcdmetar.cpp: At top level: Dcdmetar.cpp:1298: warning: `bool vrblVsby(char *, char *, Decoded_METAR *, int *)' defined but not used ["SaveStartGroup" is not actually used uninitialized, so this is an annoyance; we would have to give it an initialiser, even though it would be redundant. "vrblVsby" is an unused static function which should probably be removed or used.] Making all in threads In file included from SGThread.cxx:9: SGThread.hxx:58: warning: comma at end of enumerator list [We should correct this. Although a trailing comma can be considered neat and handy, we do not expect to be able to put one after a list of variables or function arguments, so we should not do so here. I am guilty of another instance of this, in FG's viewer.hxx.] --------------------------------------- _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
