[Phoenix-pm] perl eval and the No Execute chips

[Paul Balyoz]

Think about how Perl "runs" any Perl code:

1. it compiles the source code, producing a binary version really really
quickly
     (this implies the executable code is placed somewhere else in memory -
     an executable block, for sure -
     it surely wouldn't be compiled back into the same memory spot where the
source code lives!)

2. execute the binary version that was just compiled.

So I don't think you have anything to worry about.

Besides, if Perl does fail on any future hardware/OS change, you can bet
that the Perl development team would release a patch for that pretty darn
quickly.  We're talkin' Open Source, here, after all.  :)

-- paul


On 9/13/06, Jerry Davis <jdawgaz at cox.net> wrote:
>
> On Wed, 13 Sep 2006 17:37:06 +0000
> Scott Walters <scott@> wrote:
>
> > Stops executing, starts parsing/compiling again, and then executes the
> > result of that again.  I've said it before and I'll say it again...
> > 95% of the time people eval, they really want a closure instead.
>
> the reason I asked, is that I do make use of eval, and in what I think
> is a legal way.
>
> what I normally do in an eval, is on the command line I pass the name
> of a file which is really a short perl script which is really a hash
> full of static data.
>
> sort of like:
>
> our %h;
>
> $h{somekey}{somesubkey} = value;
> ...
>
> I then eval this file, which sets sets up my all my data, and I just
> use that data in the program.
>
> Different files hold exactly the same hash but with different values.
>
> This has worked really really well for me, and I was just a little
> alarmed over what I saw on /.
>
> Jerry


Paul Balyoz
Fastech Learning Center
http://www.FastechLC.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/phoenix-pm/attachments/20060914/51abda97/attachment.html