emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warnings compiling Emacs 22 on amd64


From: Eli Zaretskii
Subject: Re: warnings compiling Emacs 22 on amd64
Date: Wed, 17 Jan 2007 00:43:24 +0200

> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> Date: Tue, 16 Jan 2007 00:16:54 -0500
> 
> I think we should demand some way to turn off the warning in specific
> places.  Does GCC have a feature to turn off warnings in a specific
> piece of code?  I don't remember.  It would be a good feature to have.

I don't think GCC has something like this.  But even if it had, such
features in other compilers either reference a warning by its code
(something like W4589), or by the command-line switch that turns that
warning off globally.  The former is both ugly and unreadable, to say
nothing of maintainability.  The latter requires that a command-line
option exist to control the warning, which in this particular case we
don't have.

> However, a specific feature just for this kind of warning would also
> be useful.  I have an idea for what it could look like: an extra cast.
> 
>       if ((int)(short)foo > (int)SHRT_MAX || (int)(short)foo < (int)SHRT_MIN)

This won't work in the context such as our FIXNUM_OVERFLOW_P macro,
since it is specifically needs to DTRT when `foo' is not a short, but
int or long.

But even if this worked, I think it obfuscates the code too much.

I don't know what important situations triggered the introduction of
this warning at such a basic level of diagnostics, but the result is
that GCC now flags perfectly valid and legitimate code as
questionable.  I think this is unacceptable when GCC runs without any
"-Wxxx" option.  So I think we should ask GCC maintainers to produce
this warning only under -Wall.  I think this is the best alternative,
on balance.  Tests like the above are about the only valid way in C to
test the width of data types, so GCC should not flag it as suspicious
unless asked to.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]