Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^3: The error says the value is uninitialized, but it works anyway

by AnomalousMonk (Archbishop)
on Aug 18, 2019 at 08:21 UTC ( [id://11104643]=note: print w/replies, xml ) Need Help??


in reply to Re^2: The error says the value is uninitialized, but it works anyway
in thread The error says the value is uninitialized, but it works anyway

Why is it basically impossible to easily force user input to be a number if it's not a whole number?

mizducky:   Further to the posts of shmem here and afoken here:   It's not (basically impossible, that is). Perl tries hard to obey the Do What I Mean (DWIM) principle. Perl has not, unfortunately, been blessed with powers of telepathy or clairvoyance, but it does what it can within reason. In particular, Perl will try to seamlessly convert back and forth between numbers and strings. Here are some concrete examples. All the examples in this post have warnings and strictures fully enabled.

If you try to add strings that look like integers, floats, etc., the results should be pretty much as you expect (or I should say, as Perl expects you expect):

c:\@Work\Perl\monks>perl -wMstrict -MData::Dumper -le "my $x = '1.23' + qq{0.34 \t\n\r} + '5.6e3' + '100'; print Dumper $x; ;; $x = $x + 98.6; print Dumper $x; ;; my $y = 0 + $x; print Dumper $y; " $VAR1 = '5701.57'; $VAR1 = '5800.17'; $VAR1 = '5800.17';
Note that one of these strings, qq{0.34 \t\n\r}, has a bunch of whitespace padding at the end and still adds correctly. (I use the generic  qq{...} double-quote operator only because Windows command line turns up its nose at common  "..." double-quotes.) In the Dumper output in this example, the single-quotes around the nummbers (e.g., $VAR1 = '5601.57') indicate that Perl still sees these scalars as strings even after an arithmetic operation with a literal number (update: but see haukex's reply), but what care you as long as the numeric | arithmetic results are correct? (Actually, I can't say offhand just how I would force a scalar into strict "numeric" mode. Shall we say this is left as an exercise for the reader?)

You mention difficulty with a numeric string taken from STDIN. Because it's a newline-terminated string, it should behave just like the highly whitespace-padded string in the foregoing example. (Normally, a program would use chomp to get rid of newline termination on input from STDIN or a file handle, but in this example it's not necessary.)

c:\@Work\Perl\monks>perl -wMstrict -MData::Dumper -le "my $x = <STDIN>; print Dumper $x; ;; my $y = 56.7 + $x; print Dumper $y; " 2.34 $VAR1 = '2.34 '; $VAR1 = '59.04';
Question: why does the Dumper output
$VAR1 = '2.34
';
above look a bit odd? You don't give an example of the code involving STDIN that gave you difficulty; this is always helpful — see Short, Self-Contained, Correct Example.


Give a man a fish:  <%-{-{-{-<

Replies are listed 'Best First'.
Re^4: The error says the value is uninitialized, but it works anyway
by haukex (Archbishop) on Aug 18, 2019 at 08:33 UTC
    In the Dumper output in this example, the single-quotes around the nummbers (e.g., $VAR1 = '5601.57') indicate that Perl still sees these scalars as strings

    Actually, one has to be very careful with statements like these - there is no reliable way to ask Perl for the difference between e.g. 1 and "1". Although Data::Dumper has some code that tries to peek under the hood, it's not perfect:

    use Data::Dumper; my $str = "1"; print Dumper($str); # $VAR1 = '1'; my $n = $str + 1; print Dumper($str); # $VAR1 = 1;

    Update: Pointed the link above to a better node with more references.

      What's going on here?
      perl -MData::Dumper -e '$n="1";print Dumper$n;$n++;print Dumper$n;$n-- +;print Dumper$n' $VAR1 = '1'; $VAR1 = '2'; $VAR1 = 1;

        Here is a look at the internals with Devel::Peek:

        $ perl -wMstrict -MDevel::Peek -le '$a=1; $b="$a"; Dump($a)' SV = PVIV(0x5841e3fdfc40) at 0x5841e3fe36e0 REFCNT = 1 FLAGS = (IOK,POK,pIOK,pPOK) IV = 1 PV = 0x5841e4024ad0 "1"\0 CUR = 1 LEN = 10

        Here, you can see that the variable $a has both the string component PV = "1"\0, and it is marked as valid with POK, and an integer component IV = 1, also marked as valid with IOK. So they are both valid, and as I said, there is no reliable way to ask Perl for the difference. Modules like Data::Dumper have to guess what to output based on this internal information. (AFAICT from the source, the XS implementation of Data::Dumper simply prefers the integer version when that is valid. Other dumper modules handle such cases differently.)

        What's going on here?
        use warnings; use strict; use Data::Dumper; use Devel::Peek; my $n="1"; print Dumper $n; Dump($n); $n++; print Dumper $n; Dump($n); $n--; print Dumper $n; Dump($n); __END__ $VAR1 = '1'; SV = PV(0x53a29eb00fd0) at 0x53a29eb278b8 REFCNT = 1 FLAGS = (POK,IsCOW,pPOK) PV = 0x53a29ec907b0 "1"\0 CUR = 1 LEN = 10 COW_REFCNT = 1 $VAR1 = '2'; SV = PV(0x53a29eb00fd0) at 0x53a29eb278b8 REFCNT = 1 FLAGS = (POK,pPOK) PV = 0x53a29ec3f310 "2"\0 CUR = 1 LEN = 10 $VAR1 = 1; SV = PVIV(0x53a29eb23ac0) at 0x53a29eb278b8 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 1 PV = 0x53a29ec3f310 "2"\0 CUR = 1 LEN = 10

        As you can see, what happens in this case internally is that the postincrement keeps only the string component, while the postdecrement converts it to an integer. If I had to guess why this is is the case, it might have to do with the "magic string increment" feature.

        However, these are internal implementation details that one should not rely on!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11104643]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (4)
As of 2024-03-29 00:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found