This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]