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
