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).

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.

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.

Not to mention voiding your perl warranty.

Does this mean that I can return my Perl under warranty when I segfault it?

:-)

Yes. Apply rm -rf to suitable portions of your hard drive to return it.