Date:	Mon, 14 May 2001 10:25:26 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	DJ Delorie <dj AT delorie DOT com>
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:	<Pine.SUN.3.91.1010514100657.24166P-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -