So time ago 迪拉斯 told me I should not use my together with a condition. He told me it's undefined behaviour, if the contrition is not met and asked me what am I expecting to have in the variable if the condition is not met. I was expecting undef and it actually worked like that. I was not too much excited and just told my self "let's just don't do it from now on".
Days passed and one day we got a strange behaviour in our mod_perl application. A variable was set even it was not supposed to be. The reason was simple. The condition was not met, but instead of undef the variable had the value from a previous request... Was funny in our case but in others it could lead to security problem.
Lesson learned - next time pay more attention to what my colleagues are telling and never use my+if
perlcritic (Score:1)
Perl::Critic warns against this, try checking your code with it.
A better way (Score:1)
Persistem my variables? (Score:1)
If I get it right the faulty statement was something like:
my $var = 'passed' if cond();, right? This looks really strange and funny to me. I understand it as execute this statement (which declares a variable) only if the condition is true. If the condition is false then the statement shouldn't be executed, thus no creation of variable. That's not what Perl might do as I'm expecting Jozef to be using "strict" and his module might have not compiled otherwise avoiding this peculiar situation. You where usinRe: (Score:1)
It generally keeps the “pad” (the allocation space for lexicals, basically) around. Sometimes, eg. for recursive calls, it will allocate extra pads that may be garbage-collected later. So this faux-feature actually doesn’t work reliably except in the simplest use cases. It’s a good thing that 5.10 deprecates it and 5.12 will probably throw an error for such usages.
Re: (Score:1)
Maybe this is what you all are missing. (Score:1)
Re: (Score:1)
That does not work any better.