Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Automatically Converting Perl to C

by blueberryboost (Novice)
on Apr 01, 2010 at 20:04 UTC ( #832373=perlquestion: print w/replies, xml ) Need Help??
blueberryboost has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I would appreciate if the experts here help me with identifying a good tool that can automatically convert a Perl program to a C program. I am using Ubuntu 64 bits. I have read about p2c from however I am confused as it says that p2c is for both Pascal to C and Perl to C conversion ??? Also after installing p2c on my Ubuntu I tried to convert a program and I am getting weird errors, it seems that it expects a Pascal code. Does anybody know about a better tool? Or does anybody have experience with using p2c for translating Perl to C? Thank you very much!

Replies are listed 'Best First'.
Re: Automatically Converting Perl to C
by Corion (Pope) on Apr 01, 2010 at 20:08 UTC

    It's basically impossible to write an automatic converter from Perl to C without also removing the possibility of significant speed gains.

    Perl has many features that C does not provide, and providing those features within C means slowing down C to the level that Perl is now. Perl is written in C.

      Please see my response to ikegami. My end goal is to get an executable that is harder to reverse-engineer than perl2exe produces. I do not mind if the resulting speed is the same or even if I loose a little from the execution speed of my current Perl program
Re: Automatically Converting Perl to C
by davido (Archbishop) on Apr 02, 2010 at 07:16 UTC

    Rather than coming up with a programming solution to protecting your work by making it a little harder to read, is it possible to achieve one of the following?

    • Copyright your work.
    • License your work to your userbase.
    • Work out a contract with your users that protects your interests.
    • Give away your work but sell support, maintenance, etc.
    • Think of some other means of protecting your interests that doesn't involve obscuring your work by enveloping it into an executable.

    My point is that creating an executable with the intent of simply making it more difficult to read what you've written (first) won't guarantee that you'll accomplish the goal, and (second) may not be the most effective approach. There may be better ways to protect your interests. Think a little outside the technical box and you may come up with a real-world solution that is more appropriate.


      Dave, Thanks for your suggestions. Unfortunately in the particular niche I am working I need more protection than the "non-technical solutions" you have kindly listed. Also, the constraint that I have right now is that an executable needs to leave my hands, I cannot at this point keep the exec on my machine ans allow remote access through an API...
Re: Automatically Converting Perl to C
by belg4mit (Prior) on Apr 01, 2010 at 22:12 UTC

    In Bob We Trust, All Others Bring Data.

      Thanks for the info. Does anybody here have any experience positive or negative with B:C?
        It used to have a reputation of not quite being all there, but someone's taken up development of it recently so things are probably improving.

        In Bob We Trust, All Others Bring Data.

Re: Automatically Converting Perl to C
by ikegami (Pope) on Apr 01, 2010 at 23:03 UTC
    What is your real goal? Is it really to get C, or is it something else like creating a distributable executable or making the code faster.
      First thanks everybody for taking your time to answer my question. My goal is to get from my program something secure, an executable hard to reverse engineer to extract the code. I read that perl2exe is easily reversible, however C executables are much harder to break. In terms of performance I would be very happy if my executable is as fast as my Perl is, I could even live with something that is not significantly slower...
        however C executables are much harder to break

        That is a common myth, it simply isn't true.

Re: Automatically Converting Perl to C
by doug (Pilgrim) on Apr 02, 2010 at 18:29 UTC

    I think that we've been here before. Lots of words can be said, but basically if you want to "protect" the source, use a compiled language. You can embed a perl program from within a C program. In fact, the perlembed man page explains how to do it.

    - doug


      Thank you for your reply.

      Let me make sure that I understand: so you are suggesting embedding the Perl program (that contains the IP) in some sort of C wrapper program and then compiling the C program?

      If this is the case what is the executable that I deliver? Is this a standalone C executable? will the Perl program need to be provided in addition to this executable or the Perl code will be "hidden" (I understand that not completely...) INSIDE this executable?

      I would appreciate a pointer to an example where perl code is embeded in a C wrapper to be (C) compiled. Thanks.

        That's not going to help you. It's trivial to break that "protection". Why do you persist in not believing many, many people who tell you that your approach will not work?

        If you embed the entire Perl program verbatim in your C code, I can use the strings binary to pull out the Perl program verbatim.

        If you obfuscate the Perl program within the C code to defeat the strings attack, but link dynamically against libperl, I can subvert the dynamic loader to load my own binary instead which prints the Perl code instead of evaluating it.

        If you obfuscate the Perl program within the C code and statically link against Perl, I can attach a debugger and find the point at which you call into Perl and dump the Perl program from running memory.

        (If you don't understand exactly what I mean by any of this and you don't know exactly how to do any of it, you're certainly not a strong enough programmer to implement any of them. I don't mean to sound harsh, but these are basic security attacks against even strong obfuscations.)

        This is almost a law of physics: You cannot rely on the security of any information provided to a hostile client.

        >I would appreciate a pointer to an example where perl code is embeded in a C wrapper to be (C) compiled. Thanks.

        like here?

        Cheers Rolf

Re: Automatically Converting Perl to C
by SuicideJunkie (Vicar) on Apr 05, 2010 at 13:31 UTC

    I suggest that wrapping it in an executable should be considered a social measure. Its a clear sign that you don't want people to poke in there, although it won't stop them if they try.

    In addition to appropriate contracts & licenses as above, you might also consider adding a watermark to the code to identify who leaked it when it inevitably gets out in a few years. Then bill the culprit for the extra copies floating around and/or damages incurred (write that part into the contract of course).

    The only way to actually prevent the code from leaking is to keep it on trusted hardware being accessed only by trusted people ... even then, you can't be sure they're trustworthy or the only ones with access, but that is closer to a physical security issue. It also sounds like it isn't practical for your purpose.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://832373]
Approved by kennethk
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (1)
As of 2018-03-24 02:40 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (297 votes). Check out past polls.