in reply to Re^2: String increment - reasoning
in thread String increment - reasoning

I would be hesitant to ask for whole lot of special condition checks on this operator, for fear of slowing down all the scripts that use it so often.

Maybe, but given that (assuming I understand correctly), the following is the code that implements the string increment:

... d = SvPVX(sv); while (isALPHA(*d)) d++; while (isDIGIT(*d)) d++; if (*d) { #ifdef PERL_PRESERVE_IVUV /* Got to punt this as an integer if needs be, but we don't issue warnings. Probably ought to make the sv_iv_please() that does the conversion if possible, and silently. */ const int numtype = grok_number(SvPVX_const(sv), SvCUR(sv), NULL); if (numtype && !(numtype & IS_NUMBER_INFINITY)) { /* Need to try really hard to see if it's an integer. 9.22337203685478e+18 is an integer. but "9.22337203685478e+18" + 0 is UV=9223372036854779904 so $a="9.22337203685478e+18"; $a+0; $a++ needs to be the same as $a="9.22337203685478e+18"; $a++ or we go insane. */ (void) sv_2iv(sv); if (SvIOK(sv)) goto oops_its_int; /* sv_2iv *should* have made this an NV */ if (flags & SVp_NOK) { (void)SvNOK_only(sv); SvNV_set(sv, SvNVX(sv) + 1.0); return; } /* I don't think we can get here. Maybe I should assert this And if we do get here I suspect that sv_setnv will croak. N +WC Fall through. */ #if defined(USE_LONG_DOUBLE) DEBUG_c(PerlIO_printf(Perl_debug_log,"sv_inc punt failed to co +nvert '%s' to IOK or NOKp, UV=0x%"UVxf" NV=%"PERL_PRIgldbl"\n", SvPVX_const(sv), SvIVX(sv), SvNVX(sv))); #else DEBUG_c(PerlIO_printf(Perl_debug_log,"sv_inc punt failed to co +nvert '%s' to IOK or NOKp, UV=0x%"UVxf" NV=%"NVgf"\n", SvPVX_const(sv), SvIVX(sv), SvNVX(sv))); #endif } #endif /* PERL_PRESERVE_IVUV */ sv_setnv(sv,Atof(SvPVX_const(sv)) + 1.0); return; } d--; while (d >= SvPVX_const(sv)) { if (isDIGIT(*d)) { if (++*d <= '9') return; *(d--) = '0'; } else { #ifdef EBCDIC /* MKS: The original code here died if letters weren't consecu +tive. * at least it didn't have to worry about non-C locales. The * new code assumes that ('z'-'a')==('Z'-'A'), letters are * arranged in order (although not consecutively) and that onl +y * [A-Za-z] are accepted by isALPHA in the C locale. */ if (*d != 'z' && *d != 'Z') { do { ++*d; } while (!isALPHA(*d)); return; } *(d--) -= 'z' - 'a'; #else ++*d; if (isALPHA(*d)) return; *(d--) -= 'z' - 'a' + 1; #endif } } /* oh,oh, the number grew */ SvGROW(sv, SvCUR(sv) + 2); SvCUR_set(sv, SvCUR(sv) + 1); for (d = SvPVX(sv) + SvCUR(sv); d > SvPVX_const(sv); d--) *d = d[-1]; if (isDIGIT(d[1])) *d = '1'; else *d = d[1];

I think the cost of the test required to notice that the string doesn't meet the specified requirements would be minimal as the code already has to scan the string from the beginning to find the end of the complient part (if any):

d = SvPVX(sv); while (isALPHA(*d)) d++; while (isDIGIT(*d)) d++;

And it already follows that with a conditional check to detect if the scan found the end of the string:

if (*d) {

I think all it would take is the replacement of the line

sv_setnv(sv,Atof(SvPVX_const(sv)) + 1.0);

with something like:

Perl_croak(aTHX_ "String increment invalid on string '%s'", SvPVX( +sv));

There's possibly a bit more to it than that, but would that have a huge impact upon performance?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."