Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: hex numbers

by shmem (Chancellor)
on Jan 14, 2021 at 18:06 UTC ( [id://11126922]=note: print w/replies, xml ) Need Help??


in reply to Re: hex numbers
in thread hex numbers

And this works but you shouldn't use it:
# This works but is NOT recommended, and can be unsafe. my $n = eval "0xDEADBEEF"; print "$\n"; # Output: # 3735928559

It is not unsafe. "0xDEADBEEF" is a string constant. It is just as if 0xDEADBEEF had been put into the source code at the first place, with the difference that the literal is evaluated at compile time, whereas eval "0xDEADBEEF"; is evaluated at run time. Neither of them is safer than the other.

String eval is not unsafe per se - but it is unsafe if applied upon strings of dubious provenience. Every piece of perl code (which is a bunch of strings) is eval-ed by the perl binary.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^3: hex numbers
by davido (Cardinal) on Jan 14, 2021 at 19:14 UTC

    I'm certainly aware that many modules even do this:

    our $VERSION = "1.2.3_001"; $VERSION = eval $VERSION;

    As documented in perlmodstyle, I think. The specific code I used in the example isn't unsafe. But the evaluation of a string can be unsafe if the string's source isn't well controlled. And if the original poster were able to hard code hex, he could do so using 0x literals. Since he's not using 0x literals, I assume that's because the hex strings are coming from somewhere external. And at that point the caveats about evaluating strings apply.

    But you're correct. What I posted isn't inherently unsafe. The practice is inherently easy to make unsafe, though.


    Dave

      The practice is inherently easy to make unsafe, though.

      This is true. I should have posted the following rewrite of your example

      # This works but is NOT recommended, and can be unsafe. my $s = "0xDEADBEEF"; # here we assign from a constant - but where # does the value come from in your code? my $n = eval $s; print "$n\n"; # Output: # 3735928559

      which makes that point clear. It is not the eval of a string constant, hard coded into a program which is unsafe, but eval'ing a string from elsewhere.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

        That is totally reasonable.

        My assumption was that if I didn't throw up a big red flag that implementation would have been the one that got used, and then we would be promoting a high risk behavior. Your comment is better.


        Dave

Re^3: hex numbers
by haukex (Archbishop) on Jan 14, 2021 at 18:17 UTC
    It is not unsafe.

    davido didn't say that: "This works but is NOT recommended, and can be unsafe", and at least to me it's obvious that this refers to what you said:

    it can be unsafe if used upon strings of dubious provenience

    If one is doing eval, one is usually using it on strings based on user input or dynamically generated strings, otherwise one wouldn't have to eval in the first place!

    Stringy eval is one of those "only do this if you really know what you are doing" type of things, so while your clarification certainly isn't wrong, I also think warning against it is absolutely the right thing.

      davido didn't say that: "This works but is NOT recommended, and can be unsafe", and at least to me it's obvious that this refers to what you said

      Using string eval on a proper hex string constant can not be unsafe. While warning aubout string eval composed of user input or some such is appropriate, it is not for this construct. Warnings should be correct. Saying to a girl "if you kiss that boy you'll get pregnant!" is, albeit often turning out true in the long run, incorrect and misleading. Hence my comment.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
        And of course code which assumes that the string can only ever contain hex digits is an exploit waiting to happen.

        Dave.

        Using string eval on a proper hex string constant can not be unsafe.

        Of course not, but again, it is a matter of how likely it is the OP is doing that vs. the string coming from outside the program.

        While warning aubout string eval composed of user input or some such is appropriate, it is not for this construct.

        Your interpretation of "This works but is NOT recommended, and can be unsafe" is very different from mine, but I've already explained myself.

        Warnings should be correct. Saying to a girl "if you kiss that boy you'll get pregnant!" is, albeit often turning out true in the long run, incorrect and misleading.

        I don't agree with that comparison; I personally think stringy eval is dangerous enough to compare it to unprotected sex instead of kissing, in which case your post is the one that is misleading. But this moving into the area of opinions, which we could argue about all day. I did say that your clarification of the warning is a good thing, I just personally wouldn't have worded it as strongly as you did.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (4)
As of 2024-03-29 05:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found