This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: gets with C++ and GCC before 4.7
On Tue, 6 Mar 2012, Roland McGrath wrote:
> > As I said in the gcc bug, gcc should define a macro if the declaration
> > is needed and this macro should be defined only when absolutely
> > necessary.
>
> No solution in that direction works without modifying GCC releases that
> have already been made.
Indeed. The headers should work with existing releases as a practical
matter and my patch does the minimum to enable them to work. I think it's
appropriate to go into glibc on that basis.
> Getting 4.7 and later to define a macro that says
> the declaration can safely be omitted seems like a better bet.
Several possible solutions were discussed in GCC bug 51785. The one that
got implemented isn't ideal - because it involves a configure test things
may still break if glibc is upgraded after GCC is installed - and it may
be possible to change it to a better solution later (the GCC bug is still
open).
But, things should not have been left broken in the first place while
people discussed possible solutions. That's bad for people building and
testing the tools in much the same way as it's bad to break the build or
testsuite run by checking in untested patches. Multiple parts of the GNU
toolchain are often built and tested together, so it's important to
cooperate on such issues.
We recently discussed patch reversion rules for patches causing
regressions that don't get fixed very quickly, and there seemed to be some
support for something like the GCC patch reversion rules
(regression-causing patches generally to be reverted after 48 hours if
there's no sign of a proper fix soon and some agreement among developers
that reversion is the right approach in that case - which of course
depends on the seriousness of the regression). I think it's appropriate
to consider regressions in the combination of multiple tools as well: if a
glibc patch causing problems can be identified then it may be appropriate
to revert it, *even if in some sense glibc is in the right and the bug is
in another component*, until a proper resolution can be worked out across
multiple components.
Indeed, I did put in such an interim fix two months ago (commit
8ecd6b2a1283a28bcf56cfe48099fafa412a3929,
<http://sourceware.org/ml/libc-alpha/2012-01/msg00028.html>). That added
a comment mentioning _GNU_SOURCE being predefined by GCC as an explanation
of the logic for C++. The subsequent reversion-and-filing-GCC-bug (commit
c3a87236702cb73be1dada3438bbd3c3934e83f8) then left things broken for two
months.
That's not helpful; I think multi-component issues should be coordinated
in a way that keeps things working as far as possible while all components
work through the changes rather than one component leaving them broken
until another component changes. I think we should agree this as good
practice for multi-component changes and document it as such on the wiki -
on the basis that if it seems difficult to achieve in a particular case
then the issue needs to be properly discussed on the mailing lists for all
affected components before deliberately making any change in a way that
leaves things broken if the discussion concludes that to be necessary for
some reason.
--
Joseph S. Myers
joseph@codesourcery.com