Misleading warning "Use of uninitialized value $x in numeric eq (==)" when comparing value of $x from core function #21930
Comments
|
This is also an interesting example which seems like handcrafted: $ perl -wE 'my @a; say( shift(@a) == 0 )'
Use of uninitialized value within @a in numeric eq (==) at -e line 1.
1 |
mauke
added a commit
to mauke/perl5
that referenced
this issue
Feb 6, 2024
When perl looks for the source of "uninitialized value" warnings, it
treats length() as transparent: length(X) is undef iff X is undef, so it
makes sense to ignore length() when looking for the origin of the undef
value. However, this makes for misleading diagnostics: If $x is undef,
then 'length($x) == 0' triggers a "Use of uninitialized value $x in
numeric eq (==)" warning. This is correct insofar as (==) encountered an
undef value and $x is its origin, but incorrect in that $x is not one of
the operands of (==) in the source code.
This patch skips over length() when looking for the origin of undef (as
before), but adds "length(...)" around the name of the variable found,
if any.
Before:
$ perl -we 'my $x; $_ = length $x == 0'
Use of uninitialized value $x in numeric eq (==) at -e line 1.
(Misleading: $x is not an operand of (==).)
After:
$ perl -we 'my $x; $_ = length $x == 0'
Use of uninitialized value length($x) in numeric eq (==) at -e line 1.
See also: Perl#21930
|
I've pushed a potential fix in mauke@f5862f5. |
This would not be an option IMO, length on an undefined value is fine and should pass on the undefined value. |
That looks sensible to me. |
mauke
added a commit
to mauke/perl5
that referenced
this issue
Feb 7, 2024
When perl looks for the source of "uninitialized value" warnings, it
treats length() as transparent: length(X) is undef iff X is undef, so it
makes sense to ignore length() when looking for the origin of the undef
value. However, this makes for misleading diagnostics: If $x is undef,
then 'length($x) == 0' triggers a "Use of uninitialized value $x in
numeric eq (==)" warning. This is correct insofar as (==) encountered an
undef value and $x is its origin, but incorrect in that $x is not one of
the operands of (==) in the source code.
This patch skips over length() when looking for the origin of undef (as
before), but adds "length(...)" around the name of the variable found,
if any.
Before:
$ perl -we 'my $x; $_ = length $x == 0'
Use of uninitialized value $x in numeric eq (==) at -e line 1.
(Misleading: $x is not an operand of (==).)
After:
$ perl -we 'my $x; $_ = length $x == 0'
Use of uninitialized value length($x) in numeric eq (==) at -e line 1.
Fixes Perl#21930.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Module: —
Description
I am comparing the length of a string. It happened to be undefined but the warning was misleading and made me think the logic of my comparison was broken. The warning reads like my code was missing parenthesis and compiled into
length( $x == 0 )which it didn’t.I think this was probably discussed before and I am not the first to bring this up but googling this yields a ton of posts about low quality code which produced the warning and users trying to figure out its basic meaning.
Steps to Reproduce
The warning is incorrect: not
$xis compared butlength($x). I confirmed this behavior forabs($x)length($x)delete()on hash keys:Expected behavior
It’s probably hard to implement a generic representation of the expression. So any of those:
Use of uninitialized value length($x) in numeric eq (==)(I think, it might be possible as it looks like there is already special handling for core functions.)Use of uninitialized value $x in lengthUse of uninitialized value in numeric eq (==)like for user-defined functions:Perl configuration
The text was updated successfully, but these errors were encountered: