in reply to Blending perl and C (two approaches)

I think a more fundamental question here is: what benefit do you think is being created by keeping the perl source code hidden? This is obviously not a benefit for the end user -- the only conceivable benefit would be to satisfy some perception you have (or your employer has) about the importance of retaining exclusive ownership of the code and not allowing anyone else to view it.

So this raises two additional questions:

If exclusive protection of source code is unavoidably essential to you, maybe you should just re-implement the perl script in a compiled language.

Apart from that, your idea of having a C program do system( "perl -e 'eval{hugestring}'" ) might work if your perl source code is tweaked with this idea in mind: don't use single-quotes anywhere in the perl source code. (Perl gives you plenty of ways to avoid using single-quotes.)

UPDATE: Having just seen this reply from dave_the_m, I should say that this approach "works" in the sense that it will probably run -- not that it will actually protect your source code from exposure. (/update)

Changing the perl source code just to support that sort of application is admittedly a kluge, and might raise maintenance issues later on ("oops! when that new function was added, we forgot about avoiding apostrophes..."), but if you are stuck in the mindset of hiding the source code, some folks would tend to expect that there are bound to be kluges, because there's no way to prove otherwise.

If the "protection" of source code is a matter of trying to preserve your "market share", you should understand that eventually you are bound lose market share to anyone who finds a way to address the same task but doesn't care about hiding their source code.

If the source code protection is a matter of preserving particular data from unauthorized viewers, that's a different matter: just separate the data from the source code, and encrypt the data, not the source code.

Replies are listed 'Best First'.
Re^2: Blending perl and C (two approaches)
by holandes777 (Scribe) on Oct 31, 2007 at 15:04 UTC
    I hear you loud and clear!
     
    Actually the data can be made completely public. It is the method whereby it is gathered and organized that requires protection. Essentially we have to create a barrier that shows the program was tampered with if the results are wrong. Think of the law: If your door is unlocked then the burglar will probably be in less trouble than if he has to break something to get in.
     
    The protection need not be perfect becasue the potential hacker base is small and NTTB (Not Too Terribly Bright)
     
    In any event, to all of you, the comments are really valuable. I am impressed with the genuine interest each of your responses show. I am proud to belong to this organization.