fix regexec with haystack strings longer than INT_MAX
authorRich Felker <dalias@aerifal.cx>
Thu, 6 Oct 2016 16:15:47 +0000 (12:15 -0400)
committerRich Felker <dalias@aerifal.cx>
Thu, 6 Oct 2016 22:47:57 +0000 (18:47 -0400)
commitaee6abb2400b9a955c2b41166db1c22f63ad42ef
tree09d65ed801ea04cb1c2251439b747be06ff944e2
parentc3edc06d1e1360f3570db9155d6b318ae0d0f0f7
fix regexec with haystack strings longer than INT_MAX

we inherited from TRE regexec code that's utterly wrong with respect
to the integer types it's using. while it doesn't appear that
compilers are producing unsafe output, signed integer overflows seem
to happen, and regexec fails to find matches past offset INT_MAX.

this patch fixes the type of all variables/fields used to store
offsets in the string from int to regoff_t. after the changes, basic
testing showed that regexec can now find matches past 2GB (INT_MAX)
and past 4GB on x86_64, and code generation is unchanged on i386.
src/regex/regexec.c