Re: Is INLINE_HEADER_BEGIN still useful?

[Paul Eggert]

On 04/29/2015 08:33 AM, Oleh Krehel wrote:
> > Try './configure --enable-gcc-warnings'.  Certainly the warnings do
> > appear on some modern GCC implementations -- otherwise we wouldn't
> > have gone to all that work to suppress them so recently.
> OK, but that just makes each warning into an error.

Actually, --enable-gcc-warnings does two things.  First, it turns 
warnings into errors.  Second, it enables many warnings that are 
normally disabled.  It's intended for developers who want to apply many 
static checks to programs, partly to increase the probability that the 
programs will be portable to random platforms the developers don't have 
easy access to.

These warnings are not the default, because the default is intended for 
ordinary installation builds where we would rather have the build work 
than to have it be derailed by a false alarm.

> My build terminates
> for unused variable "spool_name", which is unused because I don't have
> the right configuration.

I regularly test --enable-gcc-warnings on a fairly-fully-loaded Fedora 
21 x86-64 host, and it should be clean there.  It's not clean on 
arbitrary configurations, and isn't intended to be clean everywhere 
because that would be a of hassle for not-that-much payoff.

If you regularly use --enable-gcc-warnings for development (which is a 
good idea, if you're editing the C code), and if it has false alarms for 
you, please feel free to fix them.  If it's just a matter of missing 
libraries, though, I expect it would be better to install the libraries, 
if only so that you can check that your changes don't hurt calls to 
those libraries.

> > > Maybe someone on the list
> > > could respond if they use a compiler that doesn't support the C99
> > > "inline" declaration?
> > It's not as simple as that.  Although most compilers have grokked the
> > 'inline' keyword for some time, this does not imply full support for
> > C99 'inline' everywhere.  For example, OS X 10.8's standard headers do
> > not work when used by extern inline functions, so Emacs can't simply
> > assume C99 inline will work on this relatively recent platform
> > (released July 2012 and still in wide use).
> Not all inline are extern inline, buffer.h doesn't need to be extern
> inline, if I understand correctly.

Why not?  You can't just make those functions plain 'inline', as that 
would not conform to the C99 rules and would not be portable.

> One more question, is there a list of platforms on which Emacs is known
> to build fine, by version?

Sorry, not that I know of.  The list of platforms would be pretty large, 
as Emacs is portable to a lot of platforms that are constantly mutating.

> Maybe 25.1 doesn't build on OS X 10.8 for
> reasons other than C99 compatibility.

No, Emacs builds on OS X 10.8.  The C99 issues aren't a problem, because 
Emacs macros like INLINE_HEADER_BEGIN work around the OS X 10.8 bugs 
with inline functions.  For more, please see m4/extern-inline.m4 (this 
file is taken from gnulib).