Re: [PATCH] posix: Sync gnulib regex implementation

[Paul Eggert <eggert at cs dot ucla dot edu>]

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.