Date: Mon, 14 May 2001 11:57:15 +0300 (WET) From: Andris Pavenis To: Eli Zaretskii Cc: DJ Delorie , djgpp-workers AT delorie DOT com Subject: Re: [PATCH] Update to compiler options for DJGPP CVS version In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 14 May 2001, Eli Zaretskii wrote: > > On Mon, 14 May 2001, DJ Delorie wrote: > > > These are all easily fixed, and in many cases makes the code easier to > > read, and thus easier to maintain. I would rather keep -Wtraditional > > in, it may spot a bug, and it helps keep the code clean and readable. > > What bugs can -Wtraditional spot? IMHO, it warns about practices which > are safe and portable except to _very_ old compilers we don't care about. I'm often using -W -Wall to compile my own sources (mostly C++) and trying to get them to compile without warnings. There are some noisances of course but usually not too much. Maybe this is what we should try (-W -Wall -Werror). There are some more warnings when -W is added about: comparission between signed and unsigned. missing values in structure initialization unused parameters (it's easy to add '(void) foo;' to force gcc not to warn that parameter foo is unused. It could also be bug when one have defined local variable foo > > > > doprnt.c: At top level: > > > doprnt.c:474: warning: traditional C rejects the 'l' suffix > > > doprnt.c:474: warning: traditional C rejects the 'l' suffix > > > doprnt.c:474: warning: traditional C rejects the 'l' suffix > > > doprnt.c:474: warning: traditional C rejects the 'l' suffix > > > doprnt.c:474: warning: traditional C rejects the 'l' suffix > > > .... > > > doprnt.c:797: warning: traditional C rejects the 'l' suffix > > > > The 'L' suffix isn't needed anyway. > > How so? Are you saying that a constant such as 1e-2048 is automatically > and silently converted by GCC to a long double type? Even if this is > true for a particular version of GCC, is it safe to take it as granted? > > > > doprnt.c:801: warning: traditional C lacks a separate namespace for > > > labels, identifier `start' conflicts > > > > Conflicts with *what* ? > > With the variable `start' in the same function. That's why it says > ``identifier'' (meaning the other, non-label use). > > > > i586-pc-msdosdjgpp-gcc -pipe ... -c mntent.c > > > mntent.c: In function `get_stacker_info': > > > mntent.c:208: warning: traditional C rejects the 'u' suffix > > > mntent.c:217: warning: traditional C rejects the 'u' suffix > > > > So use a constant without the high bit set (we're making it up anyway) > > so that we don't *need* a 'u' suffix. > > But there might be places where we do need an unsigned constant. > > > > mntent.c:864:2: warning: suggest not using #elif in traditional C > > > > So take it out and use nested #if's > > Which is much less readable. > > In sum, it certainly looks like -Wtraditional whines about issues which > make the code more readable and safer. Are the potential bugs it can > uncover really so bad that it makes sense to live with the downsides? > > Btw, what I would recommend is to consider _adding_ some -W* switches, > because the latest versions of GCC added some new ones and changed the > behavior of some of the old ones. It could be that some of these changes > are useful for uncovering more potential bugs and unsafe practices. Perhaps it could be the next step. Therefore I suggested these 3 changes (removal of -Wtraditional, replacement of -m486 and removal of -malign-* options) as the first step. Later we could return to adding some more warning options, enabling or disabling -fstrict-aliasing (which is on for gcc-3.0) etc. > Finally, we had an unfinished discussion about strict-alias, and what > should we do in the library to support that. Perhaps we should discuss > that again, if we are changing the compiler switches. Andris