Mail Archives: djgpp-workers/2001/05/14/11:29:57
> What bugs can -Wtraditional spot?
I don't know, but I do know that DJGPP's libc is very robust, and I
attribute that to being pessimistic about warnings. The more warnings
we can enable and avoid, the happier I'll be.
> 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?
I don't know; do we remember if we had a problem back when we added
those constants?
> > Conflicts with *what* ?
>
> With the variable `start' in the same function. That's why it says
> ``identifier'' (meaning the other, non-label use).
That's a good enough reason to rename the label anyway; having two
things called "start" in the same function, especially with gcc's
computed gotos, could lead to confusion (rarely, I hope).
> But there might be places where we do need an unsigned constant.
True. That isn't one of them.
> > > 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.
How so? Personally, I'd rather have the cpp macros easily identified
so they aren't confused with C constructs. (is that an if, or a #if?)
> 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?
If "living with the downsides" is limited to the kinds of things we've
uncovered, it's no big deal to live with them.
> 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.
Yes, we should review the new warning classes.
- Raw text -