Mike Hearn <[EMAIL PROTECTED]> wrote:

> As recent releases have broken more and more code, I would like to
> understand what GCCs policy on source compatibility is. Sometimes the
> code was buggy, in this particular case GCC simply decided to pull an
> extension it has offered for years. Is it documented anywhere? Are
> there any more planned breakages? How do you make the cost:benefit
> judgement call? Are there any guidelines you follow?

First, you must understand the difference between a real extension and
something that always worked with GCC but was never supposed to. In the former
group, you place things which are well-documented in the GCC manual, they are
disabled if you add the -pedantic option, are probably widely known (like many
of those GCC extensions that make it into C99 in some form, say designated
initializer), etc. In the latter group, there are all those mostly obscure
cases where there is a piece of code which is illegal by ISO standards but GCC
used to accept somehow.

The former group is handled with care, more often than not. Deprecations
usually involve a full release cycle (which is around 12 months), and they are
notified in the release notes (for instance, see
http://gcc.gnu.org/gcc-3.4/changes.html for the release notes of GCC 3.4).
Sometimes, deprecation time can be increased if users complain enough.

The latter group is basically made of bugs of the GCC compiler. "Accepting a
piece of code which is invalid" is the specular version of "rejecting a piece
of code which is valid", and I am sure everybody agrees that this is a bug. In
fact, in Bugzilla we have two keywords to mark these bugs: "accepts-invalid"
and "rejects-valid". We cannot really have a deprecation cycle to fix bugs: GCC
would be moving even slower than it does (or used to). Notice that this
situation is mostly common with C++ code, where we used to have wayyyy to many
"accepts-invalid" bugs. Every once in a while people jump in complaining about
no deprecation cycle for having fixed this or that bug which greatly affect
their codebases, but there is really nothing we can do about that.

In your __FUNCTION__ case, we are basically in the latter group. __FUNCTION__
is a well-documented extension in C90 (it's part of C99 in some form now), and
it was never documented to be a macro. The fact that was named like a macro and
worked like a macro for years is indeed unfortunate. Notwithstanding that, GCC
maintainers acknowledged its widespread use and the bug of it working like a
macro was deprecated for around 3 years. We cannot do more than that.

GCC 2.95 is really old, people *should* expect trouble while upgrading to 3.4,
or 4.0. I would be *really* surprised to hear a notransition from 2.95 to 4.0
which does not require any modification (for non-trivial codebases of course).

Giovanni Bajo

Reply via email to