Re: compiler standards (and/or min gcc version) supported with installed headers ?

[Roland McGrath <roland at hack dot frob dot com>]

I'm chiming in after this discussion seems to have settled pretty well
already, because I'm still under a huge backlog from my holiday hiatus.

The issue of tools used to build libc itself and that of tools supported
for building applications against libc are completely separate.  I don't
think they should both be mentioned casually in the same place, because
it is likely to lead to confusion.  The two questions are relevant to
quite different audiences.  The former is covered thoroughly in
install.texi and no details about that should be repeated elsewhere.
There should just be a short note making explicit that these are
entirely distinct issues and pointing to where the former is described.

The intent has always been that libc's installed headers support
compiling with the widest range of compilers possible, including both
non-GCC compilers and all permutations of -ansi/-std/-pedantic options.

As with everything, this ideal is tempered by the work required, the
ongoing maintenance burden of hairy conditional code, and priorities for
the allocation of maintainers' time.

>From a high-level perspective, the goal should be that someone who built
a given program with some compiler version and some glibc version should
be able to install a newer glibc version and rebuild the same program
source with the same compiler, same everything else but the libc
installation, and not experience regressions of any kind.  The obvious
exceptions are when we intentionally change the API incompatibly, which
is rare; and when the program's source was not using the API properly,
so it only ever worked by luck (i.e. relying on bad assumptions).

It follows that we need not be concerned with GCC versions so old that
they never actually supported the target configuration in question.
Strictly speaking, this does not exclude compiler versions that did not
support building with shared libraries, since the static-only versions
of libc (before 2.0) worked on GNU/Linux and GNU/Hurd configurations.
But this is reasonably tempered by the caveats above and the "it was
over 15 years ago, sheesh" principle, so it's not really worth worrying
about what compilers were used with libc versions before 2.0.
Similarly, we are only concerned with what was (or could possibly have
been) used on configurations for which we have had (nearly) continuous
support since: 2.0 worked on SunOS 3 and 4 on m68k and sparc, and on
4.3BSD on m68k and vax; but it no longer matters what compilers may have
been used with those configurations, since we dropped support for them
long ago.

It also follows that the calculus applies differently to
newly-introduced APIs and headers than to old ones.  If a header didn't
exist in the libc versions available when a given compiler version was
still in wide use, then it doesn't matter whether that new header in new
libc versions supports that old compiler: it can't be a regression.
Similarly, if a compiler doesn't support 'long long' then it's fine if
we just don't declare strtoll in stdlib.h, for example.

Our headers' use of both GCC extensions and post-C89 features should be
compatible and warning-free (to the extent possible) with all compilers
and -std modes, not relying on the system-headers exception.  We have
had headers using extensions for many years before the system-headers
warning behavior was introduced into the compiler.  That was added to
GCC for the benefit of non-GNU system headers, not to excuse GNU code
from judicious compatibility.  The __extension__ keyword was introduced
years earlier, specifically so that libc headers could use it, and
that's what they should do.  This requirement is tempered by the work
involved in the case of headers introduced by newer standards or as
nonstandard extensions.  For example, if a given header was invented by
C99, then it is acceptable for it not to work under -std=c89 if it's
especially difficult or ugly to make it work.  But note that a header or
API that was first introduced as a GNU extension, or for compatibility
with BSD or the like, and later standardized by ISO C or POSIX, should
not be constrained to working only in c99/gnu99 mode, for example.

Optimization issues in headers have only ever been a real concern for
GCC, and certainly moreso for more recent GCC versions.  (After all,
newer GCC versions generally optimize better than older ones across the
board, so users especially concerned with optimal code are best advised
to use newer compilers.)  However, we should endeavor not to regress
optimization for a particular compiler version from what it was in the
past.  Performance regression is in a different category than functional
regression, so the "best effort" and "maintenance burden" sorts of
caveats above have a substantially lower bar to meet when considering
dropping special optimization support for a given compiler version
vs. dropping support entirely.  But we shouldn't be dropping such
support proactively just in the name of generic simplification.

Apropos the optimization issue, I think it would be worthwhile to
document both a minimum supported version and a "strongly recommended
minimum version".  The former is the one for which we'll consider it a
valid bug report if code in a header stops compiling at all or has a
functional regression.  The latter is the one for which we'll really put
any effort at all into optimization issues.  For the latter, 3.4 or even
4.1 might be reasonable.  (The generic recommendation should be that
using the most recent stable GCC version you can use is always preferred.)

All support for non-GCC compilers is a low priority.  But we should
generally endeavor at least not to regress the support (including
optimization) from what it has been in past libc releases.

Andreas, please chew on this and cite any areas where your proposal
departs from the principles I've laid out here.


Thanks,
Roland