Re: Fix regcomp.c build for 32-bit with GCC mainline

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 20 Nov 2017, Paul Eggert wrote:

> On 11/20/2017 03:18 PM, Joseph Myers wrote:
> > On Mon, 20 Nov 2017, Adhemerval Zanella wrote:
> > 
> > > Why not use the already upstream fix from gnulib
> > > (252b52457da7887667c036d18cc5169777615bb0) ?
> > That change would not apply cleanly to current sources,
> 
> That should be easy enough to fix. Proposed patch attached.

Please commit this fix.

> > and if we have
> > over five years of regex changes out of sync with gnulib, it doesn't seem
> > a good idea to try to tie any possible resync with gnulib (in both
> > directions) to fixing build failures to make it possible to detect build
> > regressions when they occur (rather than piling one failure on top of
> > another that isn't yet fixed, so making it hard to determine the
> > problematic patch, which is the current state).
> 
> Although I didn't quite follow all that, I vaguely took it to mean "it's too
> much trouble to try to keep glibc regex code close to Gnulib". But if someone

It means that *in the context where we haven't had regression-free builds 
with GCC and binutils mainline for over two months* (over two weeks even 
if you disregard the old powerpc64le problems), and so investigation of 
regressions is routinely complicated by them having appeared while things 
were already broken for another reason, we want simple, safe fixes for 
build regressions that can be understood and reviewed quickly.  
Complicated, high-risk changes such as merging years of changes from 
gnulib need more detailed review, which would leave the build broken for 
longer, and if the build is already clean at the time such complicated 
changes go in, it makes it a lot easier to identify when those changes 
have caused build regressions.

-- 
Joseph S. Myers
joseph@codesourcery.com