2010-11-11 4 views

Répondre

2

Pas vraiment. Cela signifie que vous pouvez convertir un (petit) script Perl en un (grand) programme C, ce qui sera beaucoup plus difficile pour le destinataire de faire de l'ingénierie inverse. Dans certains cercles paranoïaques, cela peut être considéré comme un avantage (par exemple, si votre code Perl est embarrassant et que vous préférez cacher ce fait à vos clients payants). Mais la plupart du temps, elle est de valeur limitée à négative.

2

La compilation d'un programme Perl sur une optree, qui peut ensuite être exécutée, peut parfois prendre du temps. Vous pouvez sécuriser une partie de ce temps en utilisant perlcc avec n'importe lequel de ses backends. Cela va, d'une manière ou d'une autre, sérialiser l'optree compilé et le charger plus tard, lors de l'exécution de votre binaire compilé, un peu plus vite. Je peux voir cela utile dans, par exemple, les environnements CGI, pour lesquels, cependant, de bien meilleures alternatives pour éviter les coûts de démarrage sont disponibles.

Contrairement à croire populaire, perlcc ne le rend pas très difficile de désosser le binaire résultant, comme indiqué dans How can I reverse-engineer a Perl program that has been compiled with perlcc?

+0

Pourriez-vous donner des détails sur les solutions de rechange afin d'éviter les coûts de démarrage pour CGI? – Konerak

+2

Un bon moyen d'éviter les coûts de démarrage répétés serait de ne pas démarrer votre application de manière répétée. C'est-à-dire, n'utilisant pas CGI, qui exécutera votre programme à chaque demande. Au lieu de cela, par exemple, utilisez un processus persistant qui exécute votre application et demandez à votre serveur Web de lui en parler. FastCGI est un moyen très populaire de le faire, et il y en a beaucoup d'autres. – rafl

+0

Notre code (une application web assez complexe) utilise FastCGI. Fonctionne bien. mod_perl est un autre choix. – GeneQ

Questions connexes