Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^2: Checking for duplicate subroutine names

by SirBones (Friar)
on Oct 12, 2012 at 20:34 UTC ( #998785=note: print w/replies, xml ) Need Help??

in reply to Re: Checking for duplicate subroutine names
in thread Checking for duplicate subroutine names

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



"This bounty hunter is my kind of scum: Fearless and inventive." --J.T. Hutt
  • Comment on Re^2: Checking for duplicate subroutine names

Replies are listed 'Best First'.
Re^3: Checking for duplicate subroutine names
by ww (Archbishop) on Oct 13, 2012 at 02:20 UTC
    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.

Re^3: Checking for duplicate subroutine names
by kcott (Chancellor) on Oct 13, 2012 at 06:04 UTC

    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.

    -- Ken

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


      "This bounty hunter is my kind of scum: Fearless and inventive." --J.T. Hutt

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://998785]
[choroba]: Good morning!
[Corion]: I hope you had a good weekend!
[marto]: jetlag has really done a number on the kids, it's been a tough week
choroba played with the band on Saturday, so Sunday was very sleepy
[choroba]: managed to release Syntax::Construct with 5.28 support in the night, though
[Corion]: choroba: Whee ;)
[Corion]: marto: Ouch - I would've thought that kids adapt much better, but that's obviously not the case...
[marto]: well, their mother let them sleep till 15:00 & 12:00 last week, which didn't help them adjust :P
[Corion]: I was "productive" over the weekend in the sense that I revived my old "Perlmonks on SQLite" code, which likely means I can get a test instance back up running on my webhost. Small steps :)
[Corion]: marto: Ow, no, that doesn't help at all :)

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (13)
As of 2018-06-25 08:37 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.