Front page | perl.perl5.porters |
Postings from June 2013
On Sun Mar 03 06:48:09 2013, LeonT wrote: > On Sun, Mar 3, 2013 at 2:55 PM, Aaron Crane <arc@cpan.org> wrote: > > As a note for anyone looking into this further: I believe this can't > > be fixed without either (a) changing the type of mg_len from I32 to IV > > or Ssize_t (not UV or Size_t, because I think there are parts of the > > code which assume it can be negative), or (b) changing > > PERL_MAGIC_regex_global to store the value somewhere other than > > mg->mg_len. > > > > There may be back-compat issues for the former approach, since > > mg_length() currently returns a plain int and is in the public API. > > There may also be performance implications for increasing the size of > > struct magic. > > AFAICT changing mg_len shouldn't break API unless someone is taking a > pointer to it, which doesn't seem very likely. Also, mg_length is deprecated in 5.18.0. It may or may not invoke get-magic, and leaves the caller no indication as to whether it did. The length returned is in bytes, but the UTF8 flag is not set. So it’s pretty useless, except as an exercise in masochism. > > > The obvious "somewhere else" for the latter approach is presumably > > mg_obj, but I fear that implies changing storage of pos() from a > > machine integer to an SVIV, with an implied increase in memory > > footprint and pointer-chasing overhead. > > A new buffer in mg_ptr seems more logical (didn't look at the > regex_global code but if mg_len is available mg_ptr should be too). > I'd go for enlarging mg_len first though. meetoo -- Father Chrysostomos --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=116907Thread Previous