[PATCH] posix: Sync gnulib regex implementation

[Paul Eggert]

On 06/29/2018 09:00 AM, Adhemerval Zanella wrote:
> Paul, could you check what I am missing on the overflow check so we can
> move forward? I really don't want to get this sync stalled because of
> intprops.h addition as a pre-requisite.

I can add comments to  INT_ADD_WRAPV, if that would help. Please ask 
questions about it; that would help me understand what parts need better 
commenting.

I'm afraid that Florian's comment about testability is a bit of a red 
herring, as intprops.h is an internal header, not a published one. Glibc 
typically doesn't have test cases for macros defined in internal include 
files, and there's no need to test intprops.h directly. Besides, 
intprops.h and INT_ADD_WRAPV have been tested widely in commonly-used 
GNU applications like Coreutils, so it's not like I'm proposing anything 
flaky here.

That being said, this use of INT_ADD_WRAPV is unimportant (as far as I 
know, no Gnu apps use this two-buffer regex searching code any more), so 
I guess it's OK here to write a simple substitute that's good enough for 
regex even if it's not robust or general. The goal should be simplicity, 
portability, and meeting regex's needs. Proposed further Glibc patch 
attached (it assumes your patch). I've installed a similar patch into 
Gnulib.

I really don't want to get into the habit of doing this sort of thing, 
though. There's a lot of hard-won integer overflow expertise in 
intprops.h and it's a waste of time to continue to maintain poor 
imitations of it.


> I tried to check the pos-processed implementation using intprops.h for
> the snippet ... And its results are pretty much unreadable.
Trying to audit this by looking at the preprocessed output is a bit like 
auditing glibc by looking at the generated machine code. It can be done, 
but you can't expect it to be easy. For your particular compiler I 
expect that the assembly-language output is more readable than the 
preprocessor output, so if you want to look at low level stuff I suggest 
looking at assembly language. But really, you should be better off 
reading the original source (and if it needs more comments, please say 
where and why and l'll add them).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Merge-better-with-Gnulib.patch
Type: text/x-patch
Size: 4138 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20180629/4d7a810a/attachment.bin>