Re: Incrementing a Hash Value

[Abigail-II]

This is so utterly wrong, and it's unbelievable that after so many years, people keep iterating the wrong myths.

Please do provide a pointer to the documentation that garantees things will happen this way. All $i ++ is saying that $i will be incremented after the value is returned. But it is nowhere specified that $i will be incremented before or after an assignment. Its behaviour is UNDEFINED.

(And if you consider this a flame, please take your question to comp.lang.c (before you say "Perl isn't C", look up the discussion of ++ in perlop. It says that it works as in C) and really learn what being flamed is.)

Abigail

[Juerd]

a pointer to the documentation that garantees things will happen this way.

There is none.

9. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. [...]

If you want guarantees, do not use Perl.

But it is nowhere specified that $i will be incremented before or after an assignment.

$i = $i++ is deparsed to ($i = ($i++)). Having $i tied and assigning to another tied variable tells me the increment happens before the assignment.

look up the discussion of ++ in perlop. It says that it works as in C

Perlop is wrong. Did the authors of Perl re-create all compiler/platform specific postincrement issues that exist in C? If not, how can its behaviour ever be the same?

nowhere specified that $i will be incremented before or after an assignment

perl's sourcecode is the specification - MANY things are not defined in the perldocs. And fortunately, this is compiler/platform independent. Anyway. Here's your specification:

PP(pp_postinc)
{
    dSP; dTARGET;
    if (SvTYPE(TOPs) > SVt_PVLV)
        DIE(aTHX_ PL_no_modify);
    sv_setsv(TARG, TOPs);
    if (!SvREADONLY(TOPs) && SvIOK_notUV(TOPs) && !SvNOK(TOPs) && !SvP
+OK(TOPs)
        && SvIVX(TOPs) != IV_MAX)
    {
        ++SvIVX(TOPs);
        SvFLAGS(TOPs) &= ~(SVp_NOK|SVp_POK);
    }
    else
        sv_inc(TOPs);
    SvSETMAGIC(TOPs);
    if (!SvOK(TARG))
        sv_setiv(TARG, 0);
    SETs(TARG);
    return NORMAL;
}

PP(pp_preinc)
{
    dSP;
    if (SvTYPE(TOPs) > SVt_PVLV)
        DIE(aTHX_ PL_no_modify);
    if (!SvREADONLY(TOPs) && SvIOK_notUV(TOPs) && !SvNOK(TOPs) && !SvP
+OK(TOPs)
        && SvIVX(TOPs) != IV_MAX)
    {
        ++SvIVX(TOPs);
        SvFLAGS(TOPs) &= ~(SVp_NOK|SVp_POK);
    }
    else /* Do all the PERL_PRESERVE_IVUV conditionals in sv_inc */
        sv_inc(TOPs);
    SvSETMAGIC(TOPs);
    return NORMAL;
}

Pay special attention to dTARGET, sv_setsv and SETs in the postinc. As you can see, Perl does not delay the increment, but it does save the old value. (Which is because Perl can not optimise the same way C compilers do. At compile time, Perl cannot be sure if $i is a normal scalar or something special.)

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[Abigail-II]

The fact that it deparses as ($i = ($i++)) does not say anything. It still will not say anything about the order in which the assignment and the increment are done.

Did the authors of Perl re-create all compiler/platform specific postincrement issues that exist in C?

Why should they? All they had to do was follow the specifications. And the specification say that the code we are talking about has undefined behaviour.

MANY things are not defined in the perldocs.

And are hence subject to change without a deprecation cycle. Even the smallist patch might radically change the behaviour, including attempts to erase all the files from your disk. That's the nature of undefined behaviour.

Abigail