Front page | perl.perl5.porters |
Postings from December 2014
Dave Mitchell <davem@iabyn.com> wrote:
:On Fri, Dec 19, 2014 at 11:07:57PM +0000, Dave Mitchell wrote:
:> With these commits, it now passes all tests (but with zillions of run-time
:> warnings still):
:>
:> db58a81 fix integer overflow in S_regpiece().
:> a1b2073 fix integer overflow in S_study_chunk().
:> 55b6a5f fix integer overflow in S_study_chunk().
:> 646e8787 fix integer overflow in S_scan_commit().
:
:Yves/Hugo, could you review these commits? I have very little
:understanding of the regex compiler, and "fixed" those issues based on the
:vague notion that SSize_MAX probably represents infinity, and thus don't
:add to it if we're already there. But I had no detailed understanding
:of what each bit of code was doing and what the variables represent.
:And in particular, I had no clue as to whether it was possible to come
:up with test cases that demonstrate the issues.
For 646e8787 I'd probably have used '>=' rather than '>' (but it's a pretty
minor difference).
Near a1b2073 there's also an unguarded 'data->pos_delta += max1 - min1',
a few lines further up.
For db58a81, as far as I can see the only use we make of RExC_naughty
is here:
if (RExC_naughty >= 10) /* Probably an expensive pattern. */
.. so infinity is probably 10 in this case. We should probably define it
that way, and change these checks to the simpler:
if (RExC_naughty < VERY_NAUGHTY)
RExC_naughty += 2 + RExC_naughty / 2;
.. with a compile-time assert somewhere that VERY_NAUGHTY < I32_MAX / 2 - 4,
else we'll still have subtler overflows from all the ++ and +=4 scattered
around.
I'll try to look a bit more deeply later in the weekend, and maybe see if
I can audit the rest of regcomp for similar issues.
Hugo
Thread Previous
|
Thread Next