New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: which *expression* (not just scalar) was uninitialized in eq #9828
Comments
From DanVDascalescu@yahoo.comperl 5.10.0: $ perl -we 'my $x; print $x == 1' $ perl -we 'my $x; print $x->{foo} == 1' Same for string eq. --
|
From myfwhite@gmail.comThanks for the bug report! I've assigned this to the wishlist severity, because it's not urgent for |
@xdg - Status changed from 'new' to 'open' |
From @jkeenanOn Fri Aug 14 20:20:03 2009, dandv wrote:
This request was placed on the wishlist before Perl 5.12.0. Is this If so, would someone be willing to take it on? (Hint: Thank you very much. |
From @cpansproutOn Thu Aug 08 16:25:29 2013, jkeenan wrote:
Yes.
Yes, but not yet. :-)
Yes. Note that this already includes the hash element: $ perl -we 'my %x; print $x{foo} == 1' Extending that to hashes referenced by scalars is no doubt possible. -- Father Chrysostomos |
From @davidnicolOn Thu, Aug 8, 2013 at 7:57 PM, Father Chrysostomos
Extending it to arbitrary anything seems like it happen several different I'm for option 5. -- |
From @davidnicolOn Fri, Aug 9, 2013 at 7:17 PM, David Nicol <davidnicol@gmail.com> wrote:
option 4 would be easier done by simply inserting "on left" or "on right", |
From jaderd+bitcard@gmail.comOn Fri, 09 Aug 2013 17:22:14 -0700, davidnicol@gmail.com wrote:
I would like to upvote this request and the proposed solution #5. Test script $ perl -we'sub a {} sub b {} print a == b' Current output: Use of uninitialized value in numeric eq (==) at -e line 1. Desired output: Use of uninitialized value at the left of numeric eq (==) at -e line 1. |
From @xsawyerxOn 08/03/2017 01:41 PM, Jader Dias via RT wrote:
+1
Bikeshed: Is it "at the left of" or "on the left of"? |
From @iabynOn Fri, Aug 04, 2017 at 10:29:15AM +0200, Sawyer X wrote:
Before the bikeshedding, we need to decide whether its possible. The short Or more precisely, at the point where the 'uninit' warning is triggered on At this point Perl_report_uninit() has no idea whether the SV passed to it The way that Perl_report_uninit() works at the moment, is that it examines One of those rules is that if one of those args is a direct hash lookup We could add further rules and code to handle more common cases, e.g. Any ad-hoc rule we added to enable us to display 'LH' or 'RH' could just -- |
From zefram@fysh.orgDave Mitchell wrote:
Presumably the requester imagines that we could pass down an explicit The problem is that providing that explicit argument would be a lot of -zefram |
From @cpansproutOn Fri, 04 Aug 2017 04:38:28 -0700, zefram@fysh.org wrote:
Thankfully we have global variables.... If it is only pp functions that assign to (say) PL_larg and PL_rarg, and that via common macros, then what are the chances of them getting stomped on?
-- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
Oh yuck, please don't do that.
The thing that worries me is them *not* getting stomped on, and being -zefram |
From @iabynOn Fri, Aug 04, 2017 at 10:16:52PM +0100, Zefram wrote:
I think everyone needs to bear in mind that identifying the var etc in Perl currently makes a reasonable effort to do so for some common cases; I think anything that slows down all binary ops on every execution just in -- |
From @xsawyerxOn 08/05/2017 01:21 PM, Dave Mitchell wrote:
What is difficult is when it's not a variable and needs to have these
I agree. Maybe this means we should simply close the ticket with the |
From @cpansproutOn Sun, 06 Aug 2017 01:35:19 -0700, xsawyerx@gmail.com wrote:
Yes, but that information does not get propagated through the functions calls that eventually trigger an uninit warning. Solving that either slows down all binary ops (my suggestion) or entails a lot of work and a high risk of breakage (Zefram’s suggestion). Another way to do it would be to modify all binary ops to do an explicit undef check up front and warn about it, but that may well slow everything down, too.
We can still extend it to $hashref->{...} without slowing down any code that does not warn, as per the original request. I still think that is a good idea.
See the previous messages in the thread. Either we add extra parameters to numerous functions, which is a lot of work and (I think) entails a high risk of introducing regressions, or we use global variables and slow down every binary op, or we do my new suggestion of having each binary op check immediately before passing the values to other functions. They all have downsides, which are probably unacceptable. -- Father Chrysostomos |
Migrated from rt.perl.org#68534 (status was 'open')
Searchable as RT68534$
The text was updated successfully, but these errors were encountered: