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] |
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.
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 has taken the trouble to keep them closer (as in the attached patch) then we might as well keep them as close as we reasonably can. On the Gnulib side I've been trying to do that by merging glibc's changes, as in the patch I installed into Gnulib today:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=6dc8556f97cf3e7953249190b46465ad845761cf
Attachment:
0001-regex-don-t-assume-uint64_t-or-uint32_t.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |