Date: Mon, 14 May 2001 18:21:33 +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: <200105141448.KAA01828@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: > > 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? I wouldn't know: that was in the v1.x days, I believe. > > > > 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?) A matter of taste, I guess. > > 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. From the original report of Andris, I remember more nuisance like the `u' qualifier. We cannot avoid using those qualifiers altogether.