[Top][All Lists]

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

bug#23640: 25.1.50; Getting rid of compiler warnings

From: Ken Brown
Subject: bug#23640: 25.1.50; Getting rid of compiler warnings
Date: Mon, 30 May 2016 10:41:55 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0

On 5/30/2016 7:39 AM, Ken Brown wrote:
On 5/29/2016 6:43 PM, Ken Brown wrote:
On 5/28/2016 5:47 PM, Ken Brown wrote:
On 5/28/2016 2:57 PM, Eli Zaretskii wrote:
emacs_abort is declared with _Noreturn, so how come GCC doesn't shut
up about "unreachable" code?

It looks like the problem is the definition of _Noreturn as a macro in
config.h.  I'll have to figure out what's going on.

That guess was wrong.  The problem turns out to be that lint is defined
in config.h.  When lint is defined, Cygwin's <sys/cdefs.h> defines
_Noreturn to be a macro with empty expansion.  I've raised the question
on the Cygwin list
(https://www.cygwin.com/ml/cygwin/2016-05/msg00374.html) as to whether
that's a bug.

The answer is that the Cygwin's <sys/cdefs.h> is taken from FreeBSD, so
the problem will exist there too.  (I just checked the FreeBSD git repo
and confirmed that the code in question is still there.)  So it looks
like defining lint should be disabled on Cygwin and FreeBSD, at least.
Or maybe it should only be enabled on platforms where it's known that it
doesn't cause problems.

Paul, you're the one who introduced this.  What do you think?

Another glitch: Removing the line in configure.ac that defines lint results in lots of 'may be used uninitialized' warnings. That's because the IF_LINT macro now suppresses all the initializations that were previously added to avoid these warnings.

Question: Why bother with IF_LINT at all? Why not just unconditionally initialize the variables that gcc complains about?


reply via email to

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