Issue "Use of uninitialized value" warnings in left-to-right order #23108
Conversation
…t order Some binary (2-operand) operators, notably arithmetic add (+) and subtract (-), used to fetch its RHS operand first then LHS one, so they would issue "use of uninitialized value" warnings in right-to-left order: % perl -wle 'print $a + $b' Use of uninitialized value $b in addition (+) at -e line 1. Use of uninitialized value $a in addition (+) at -e line 1. 0 % I think this is not intuitive for users, as "perlop" says that "Perl has a general rule that the operands of an operator are evaluated in left-to-right order." (3-operand case is more surprising; "print $a + $b + $c" will warn in the order $b, $a, $c.) This change reverses the operand fetch order in these operators to issue warnings in left-to-right order. t/lib/warnings/9uninit: Reorder expected warnings in left-to-right order. pod/perldelta.pod: Add perldelta entry for this change.
Before this change, pp_add() and pp_subtract() had two (or three before the previous commit) calls of TARGn(<result>, 1) for each. Consolidating these calls into single call will (slightly) reduce the size of the compiled code.
There was a problem hiding this comment.
Given (a) the depth in the perl guts of the change requested, (b) the point we are at in the current development cycle, (c) the current unreliability of cpantesters.org for accepting and reporting results, I do not believe we should consider this patch for the current dev cycle. I recommend it be labeled 'defer-next-dev'.
tonycoz
added
the
defer-next-dev
|
I think this is a reasonable change.
I agree. |
|
I'm not necessarily opposed to this change, but note that it affects more than just the ordering of 'uninit' warnings. Since it changes the ordering of retrieving various ops' args, it will also affect things like the order in which FETCH() is called if both args are tied, and similarly for other magic types. Thus it could change the behaviour of existing code (which would arguably be relying on undefined behaviour). |
I think that this is not the case, as this change will only transpose So, I think that this change should not change the behavior of tied variables. |
|
On Mon, Mar 17, 2025 at 09:02:19AM -0700, TAKAI Kousuke wrote:
I think that this is not the case, as this change will only transpose
`SvXV_nomg()` which do not handle magic types, and for these binary
operators, magic types (including tied variables) are handled in
`Perl_try_amagic_bin()` (via `rpp_try_AMAGIC_2`) which already calls
`FETCH()` in left-to-right order.
So, I think that this change should not change the behavior of tied variables.
Oh yeah, silly me!
…--
31 Dec 1661: "I have newly taken a solemne oath about abstaining from plays".
1 Jan 1662: "And after ... we went by coach to the play".
-- The Diary of Samuel Pepys
|
It can change the order of |
I noticed that perl emits "Use of uninitialized value ..." warnings in right-to-left
order if both operands of a binary operator are uninitialized:
I think this is not intuitive and inconsistent with Perl's general rule of left-to-right evaluation order (mentioned in
perlop).This change will fix the order of this warning messages by reordering operand fetch.