[PATCH] posix: Sync gnulib regex implementation
Paul Eggert
eggert@cs.ucla.edu
Fri Jun 29 15:26:00 GMT 2018
Adhemerval Zanella wrote:
> I really want to make this change independent of intprops.h addition
> since previous attempts we tried to add it, some maintainers raised
> concerns about its inclusion.
As I recall the last time I suggested adding it, the only concern raised was
over the licensing boilerplate at the start of the file. I have fixed that in
Gnulib, so as far as I know the concerns have been addressed. We can make
intprops.h's addition independent by separating its addition into a separate
patch, as I proposed in my most-recent email.
> For this change I have fixed the points you raised (as you pointed out
> the semantic in indeed to wrap over values).
I'm afraid the overflow bugs still aren't fixed. Your revised change is not
portable to GCC 4 and earlier (or to non-GCC, for Gnulib), since (1) it clearly
doesn't work when 'a' is nonnegative and signed integer overflow occurs, and (2)
even when 'a' is negative it has undefined behavior with overflow.
It's pretty tricky to write this sort of code portably! intprops.h does it
right, and I'd really, reaaally rather not debug another copy of it. So let's do
things the intprops.h way.
> Just to be clear, current glibc regex do accept this pattern with
> REG_EXTENDED. And the gnulib code does report an error instead of
> accepting it. So it is not clear to me, from glibc side, if we should
> continue to accept it or if we should provide old behaviour.
This one is an easy call. The ERE (a)|\1 is malformed (in the sense that the \1
doesn't mean anything) and Gnulib is right to reject it. As I recall, current
Glibc accepts it but then has undefined behavior that usually does not crash.
The Gnulib behavior conforms to the POSIX and glibc spec, and I would say it's
clearly better for users, so let's do it.
More information about the Libc-alpha
mailing list