| commit | aee6abb2400b9a955c2b41166db1c22f63ad42ef | |
| author | Rich Felker <dalias@aerifal.cx> | |
| Thu, 6 Oct 2016 16:15:47 +0000 (6 12:15 -0400) | ||
| committer | Rich Felker <dalias@aerifal.cx> | |
| Thu, 6 Oct 2016 22:47:57 +0000 (6 18:47 -0400) | ||
| tree | 09d65ed801ea04cb1c2251439b747be06ff944e2 | treesnapshot (tar.gz zip) |
| parent | c3edc06d1e1360f3570db9155d6b318ae0d0f0f7 | commitdiff |
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.
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 | diffblobblamehistory |