Front page | perl.perl5.porters |
Postings from June 2013
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.
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.
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.
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. :)
For the record, in this case I also think one commit would have been
a (small) improvement over four.
Hugo
Thread Previous
|
Thread Next