This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Extension compatibility policy
On Sun, 27 Feb 2005, Eric Botcazou wrote:
> > In cases where breaking sources lets you achieve greater performance or
> > efficiency, please do make the change but offer a switch to disable it and
> > let the old code still compile. This way we it seems everybody can be
> > happy.
>
> My impression is that this has nothing to do with performance and efficiency,
> unfortunately.
Indeed, it's about maintainability instead, and improving maintainability
and flexibility of implementation strategies by removing an
ill-thought-out or undocumented extension is incompatible with keeping it
under a switch.
In the case mentioned of __FUNCTION__ concatenation, (a) __FUNCTION__ was
always documented as a variable, so concatentation of it was always
undocumented and so liable to removal at any time (if you like and use an
undocumented extension and want it to stay around, you need to submit
documentation for it); (b) concatenation of it should never have been
expected to make sense in view of the C phases of translation where string
constant concatenation happens in a phase before functions are identified,
so the fact it did work was really a bug; (c) the handling of string
constant concatenation has been overhauled more than once and some of
those overhauls were incompatible with concatenation of __FUNCTION__.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)