develooper Front page | perl.perl5.porters | Postings from February 2015

Re: [perl #123814] grok_atou() for regexp quantifiers

Thread Previous | Thread Next
From:
demerphq
Date:
February 16, 2015 05:37
Subject:
Re: [perl #123814] grok_atou() for regexp quantifiers
Message ID:
CANgJU+WZK5D8T4QkCjW4SZdQfwszySkB_62xxHVKqO1mhbWZPQ@mail.gmail.com
On 13 February 2015 at 19:43, Hugo van der Sanden
<perlbug-followup@perl.org> wrote:
> # New Ticket Created by  Hugo van der Sanden
> # Please include the string:  [perl #123814]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/Ticket/Display.html?id=123814 >
>
>
> AFL (<http://lcamtuf.coredump.cx/afl>) finds this:
>
> % ./miniperl -e '"z" =~ /x|y{01,}/'
> miniperl: regexec.c:6443: S_regmatch: Assertion `st->u.curly.min <= st->u.curly.max' failed.
> Aborted (core dumped)
> %
>
> This is a symptom of a bigger problem: regpiece() decides if the regexp fragment about to be parsed is a quantifier by calling regcurly(), which returns TRUE if it matches /{\d+,?\d*\/; if so, it then uses grok_atou to parse the numbers out a) assuming it will always succeed, and b) ignoring any range issues.
>
> In particular, that means if a number matches /^0\d/ it'll return MAX_UV, which is cast to I32 for initial checks (which is how the above test got past the normal min < max check), but then truncated to unsigned 16 bits (though REG_INFTY assumes signed 16 bits):

Am i understanding this to mean that grok_atou will turn any "number"
starting with 0 that is not 0 itself into MAX_UV?

That sounds less than awesome. It also makes me wonder if people
really are using this in the wild?

Why dont we just ignore the leading zeros?

Yves

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About