Date: Mon, 14 May 2001 10:48:53 -0400 Message-Id: <200105141448.KAA01828@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f From: DJ Delorie To: eliz AT is DOT elta DOT co DOT il CC: pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com In-reply-to: (message from Eli Zaretskii on Mon, 14 May 2001 10:25:26 +0300 (IDT)) Subject: Re: [PATCH] Update to compiler options for DJGPP CVS version References: 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 > 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.