Date: Mon, 14 May 2001 10:25:26 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: DJ Delorie cc: pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com Subject: Re: [PATCH] Update to compiler options for DJGPP CVS version In-Reply-To: <200105140611.CAA27953@envy.delorie.com> 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, 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. > > 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. 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.