Front page | perl.perl5.porters |
Postings from June 2013
On Sat, Jun 08, 2013 at 08:43:18AM +0100, hv@crypt.org wrote:
> Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> :* Tony Cook via RT <perlbug-followup@perl.org> [2013-06-03T08:32:13]
> :> I've applied this fix, and a few similar changes to S_regrepeat as
> :> the merge commit 285a3ca139d04d2ee1894c9a9110294ee8bb0309.
> :>
> :> I think this is a candidate for maint.
> :
> :Would some other committer please have a look at this code and comment on its
> :suitability for safey backporting?
>
> The change is essentially four variants of this:
>
> - if (utf8_target && scan + max < loceol) {
> + if (utf8_target && loceol - scan > max) {
>
> I think this is correct only if scan and loceol are guaranteed to be
> pointers into the same string, and the difference guaranteed to fit in
> I32 (the type of I<max>) without wrapping.
The difference isn't required to fit into I32 - C's promotion rules
will upgrade both sides of the comparison to the larger of ptrdiff_t
or I32, the type of the left and right sides of the comparison.
scan and loceol are pointers in the string being matched against -
scan is the current position being matched, loceol is initialized with
the end of the string and otherwise set to values within the string
(without the changes loceol could point outside the string.)
> I think the former is intended to be the case, but the docs and comments
> do not clearly indicate it, and I can't easily prove it. I've no idea
> under what circumstances the latter is guaranteed.
It's clearer with davem's changes in blead where PL_regeol has become
reginfo->strend.
> I wonder whether it would make all this significantly clearer if
> almost all these pointers were replaced with offsets. In particular,
> it might make rather more obvious if we are trying to do stuff that
> simply isn't going to work when a string can exceed 2GB.
Neither version has a problem with strings larger than 2GB, but
neither will match more than 2**31-1 items.
> I don't think the change makes anything worse, in the sense that I don't
> think there's a universe in which the new code can go wrong but the old
> code can't. But if there are any universes in which the new code can go
> wrong, then in some of those universes I believe it may go wrong more,
> or worse, than the old code. Hope that helps. :)
Please propose an example.
> For the record, in this case I also think one commit would have been
> a (small) improvement over four.
I mostly wanted to make the fixes match the tests added (for the two
cases where tests were added.)
Tony
Thread Previous