J
Joseph Myers
2. C99 features conflicting with existing C89 extensions of many
implementors. The implementors are reluctant to break their users'
code by implementing the C99 semantics of the same feature. See an
older discussion about why GNU C people don't want to change their
compiler according to C99. gcc got quite close to C99 conformance
when version 3.0 was released (over three years ago), but didn't make
any significant progress ever since...
Such conflicts are not a significant obstruction to C99 support in
GCC. Where problems arise, compatibility with old extensions
conflicting with C99 syntax is preserved under -std=gnu89. (For
example, certain uses of compound literals not permitted by C99 are
permitted with -std=gnu89. If C99 inline is implemented, that is
another case where -std=gnu89 would preserve the old semantics.)
When C99 features or other conformance improvements have been added to
GCC over the last four years has been largely determined by when I
have been able to work on implementing them and by the lack of any
funding for C99 or conformance implementation.
To answer some of the other suggestions made about missing and
incomplete C99 support in GCC:
There are no technical difficulties in preserving compatibility with
existing documented and undocumented extensions under appropriate
options, and in maintaining support for past C standard versions under
appropriate options (-std=iso9899:1990, -std=iso9899:199409,
-std=iso9899:1999). (GCC is not following the route apparently
followed by some implementations of abandoning support for older and
more widely used standard versions, nor is it abandoning extensions
without careful individual consideration.)
There are no technical difficulties in supporting C99 through
incremental changes within the current infrastructure.
There are no political objections to supporting the actual standard
rather than drafts.
It may not always be obvious whether a particular ill-designed
extension (documented or undocumented) is something that should be
kept, for compatibility with existing code or because it supports
something that can't be done within the standard, but this is dealt
with, whether or not the extension conflicts with C99, by taking care
to understand the extensions, documented or undocumented, implemented
by compiler code before changing it, so as to avoid removing
extensions by accident, discussing appropriately before removing
extensions and normally deprecating extensions for a release before
removing them if it is thought they may have a significant number of
users. Extensions are not any longer generally liked unless they add
expressive power to the language (e.g., to do machine-dependent things
which standard C cannot do) but consideration for existing users means
we take this care to stay compatible and only remove extensions with
due warning and where they cause trouble for the implementation.