Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Re: detecting $& usage

by greatdane (Beadle)
on Jan 27, 2004 at 03:10 UTC ( #324338=note: print w/replies, xml ) Need Help??


in reply to Re: detecting $& usage
in thread detecting $& usage

Thanks. My application is a verilog authoring tool that includes a perl based parser (using m/\G//). It also allow users to embed perl that I "eval". So, I am not the author of all code. If the user code uses "$&" then my tool slows down 20X. It is a big deal to this program. The parser re-evaluates the front/back of a huge string with every string search. My program crawls.

Replies are listed 'Best First'.
Re: detecting $& usage
by Abigail-II (Bishop) on Jan 27, 2004 at 09:32 UTC
    My application is a verilog authoring tool that includes a perl based parser (using m/\G//). It also allow users to embed perl that I "eval". So, I am not the author of all code. If the user code uses "$&" then my tool slows down 20X.
    Then why is it your problem? The user could put in a sleep 1_000_000_000 as well, or use a billion other ways to slow down the entire program. That's the risk you take when evalling code. You might as well disallow all Perl primitives.

    Abigail

      Then why is it your problem? The user could put in a sleep 1_000_000_000 as well, or use a billion other ways to slow down the entire program.
      It's his problem, because he's more concerned with actually accomplishing a task, rather than conforming to some bureaucratic "rules" about what is and what isn't in his job description. And since he's building verilog tool, I'll bet his "users" are highly educated engineers who are trying to get actual products out the door and he's trying to prevent any unnecessary slow downs caused by inadequate knowledge of perl trivia on the part of his users. I'd guess he is not attempting to prevent his users from being malicious. In my mind, I picture this scenario: they've got an IC tapeout 1 week away, and one of the 20 engineers on the project has tweeked some his tests a little at the last minute (to better catch bugs, because these bugs cost $1+ million in NRE per spin for a 0.1um CMOS process), and it now uses $&. It runs fine on his tiny test circuit, but when it gets rolled into the full 100 million gate IC, the test that used to take 5 hours now takes 100 hours. Oh, and they probably lose $50,000 a day in revenue for every day they slip (ouch).
        If they are highly educated, why not just say "if you use $&, the program slows down heavily", and let the highly educated engineers decide whether it matters or not.
        In my mind, I picture this scenario: ...
        I think they company would benefit much more from getting a decent testing procedure than to focus on one particular issue that might cause a slow down.

        Your situation is best described as "penny-wise, pound foolish". Except that the pounds are worth lots of dollars.

        Abigail

Re: Re: Re: detecting $& usage
by demerphq (Chancellor) on Jan 27, 2004 at 19:04 UTC

    Perhaps a simple check of their code for the offending variables, and then either reject them, or run them via a system() call to a seperate Perl process. At least that way a single use of the variables wont affect the entire body of code.

    Unfortunately the problem here is that if the engineers are crafty it will be nearly impossible to prevent them from using these vars or for detecting when they have done so.

    Which means that in the end Abigail is correct. The best way to resolve this problem is to train the engineers not to use them.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


      Thanks to everyone for all the help. This is a great site! Yes, the engineers are smart and numerous. Its hard to stop all the engineers from coding the wrong thing. Currently, the only indicator is a servere code slow down. I would prefer a more explicit indicator - a warning or blocked access. Thus, this thread. Scanning the user code is not that useful as many engineers will include (require/use) code from libraries. So, the check difficult. Its unfortunate that the test of "defined $&" causes the slow down. I will have to try the blocking tricks.

        I think you may want to reengineer what is happening a bit.

        Basically what im thinking is that you have a manager script that prepares all the appropriate stuff, and then spawns a new perl to actually run the engineer code. Thus the engineer code runs in a seperate process under a seperate perl every time. Youll get some slowdown from marshalling data between the manager script and the worker script, but it should be workable and overall resolve the problem of unexpected use of $&.

        Also with regard to your library usage, surely you can do a grep of your lib directories and simply remove or modify any library that has the offending vars in it. Obviously it would make your system non-standard, but it sounds like you have somewhat unusual requirements.


        ---
        demerphq

          First they ignore you, then they laugh at you, then they fight you, then you win.
          -- Gandhi


Re: Re: Re: detecting $& usage
by Vautrin (Hermit) on Jan 27, 2004 at 17:47 UTC
    If you are evaling perl users are uploading, then you should be able to double check the code that is being uploaded for anything you want -- including the use of $', $`, and/or $&. You could take a friendly approch (i.e. match $content =~ m/\$'/) and spit out a warning, or be a little more beligerent (exit 1 if ($content =~ m/\$'/)</code>). Of course, couldn't you put the file in a seperate file and run that as a seperate process? That would allow you to give users the power of $' with none of the problems for you.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2022-12-02 23:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?