Re^2: Checking for duplicate subroutine names

[SirBones]

Yes, absolutely understood. We are assuming a group of very local and trustworthy users; their jobs are on the line. ;-)

Cheers,

-Ken

[ww]

Um... not a good assumption.

What happens when one of them becomes disgruntled; is given notice; or the like?

Oops. Bye bye who knows what.

... and what happens, someday in the sweet bye-and-bye when the powers-that-be decide your code creates a business opportunity to be shared with customers?

[ sounds of gnashing of teeth; rending of flesh....]

Please don't do it that way.

[kcott]

My original example certainly suggests blatant maliciousness on the part of some user; however, the most trustworthy of employees, with the best intentions in the world, can write some apparently innocuous code which could have severely adverse side effects.

Consider a user-supplied subroutine which simply reads some data (e.g. get_stock_count()). What happens if that code is called while some system function (e.g. update_stock_count()), which has been running successfully for years with no ill-effects, is in the process of being run? Is the read statement of get_stock_count() executed before or after the write statement of update_stock_count()? What are the implications of this?

[Here's a potential scenario. Supplier (on the phone to User): "Is it a problem if those parts aren't delivered today?". User (after running get_stock_count()): "I've checked the stock count - we've got plenty - next week will be fine.". Production Manager (screaming at Senior Programmer the following day): "The manufacturing plant has ground to a halt. You're responsible for stock count data. User told me he ran code approved by you that reported an adequate supply. Tell me why I shouldn't sack you!"]

My recommendation would be that any user-supplied code goes through the same process of quality control (review, testing, etc.) that you'd expect to apply to your own code.

[SirBones]

I do appreciate the advice and concern, but in this case really no worries. These are isolated test beds (really isolated, they could have no possible contact with any of our production systems; for that matter their network interfaces are limited to the systems they are testing, which themselves have no external connections), with custom Linux images and dedicated hard wired interfaces. Root access is global. We end up rebuilding these things every few weeks (or days) for a number of reasons; if a user sat down and managed an "rm -rf *" I'd simply call him a bloody twerp, take away his Men's Room key, and put a new image on the thing. (I'm lying; we don't have Men's Room keys.)

The security commentary is appreciated and understood but really not a concern in this case. My concern about duplicate subroutine names is entirely based on accidental over-writes, not maliciousness. A malicious or disgruntled user would have lots of better and more effective targets. To vent hostility on the systems I am referring to would be a shamefully unsatisfying exercise for the perpetrator. (And half the time, particularly on a Friday afternoon, I wouldn't mind if they did crash a system or two.)

-Ken

[pokki]

Then you can just declare your subs in packages, as others have already said. To overwrite your own subs, users would need to name them with their fully qualified name, e.g. package Plugin; sub Core::overwritten_routine { return "foo" }. That is rather hard to write by accident.

After that, the only thing I can see to prevent (probably malicious, at this point) users from overwriting your subs is whipping up some PPI and checking any source files you require before actually requiring them. With your setup and in your environment, the hassle is probably not worth it.