Mail Archives: djgpp-workers/2001/05/14/05:12:00
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
- Raw text -