[26489] in Perl-Users-Digest
Perl-Users Digest, Issue: 8650 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 9 21:05:16 2005
Date: Wed, 9 Nov 2005 18:05:04 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 9 Nov 2005 Volume: 10 Number: 8650
Today's topics:
Re: FAQ 3.21 How can I compile my Perl program into byt <samwyse@gmail.com>
Need workaround for regex bug in 5.8.6 <jsm@jmarshall.com>
Re: Need workaround for regex bug in 5.8.6 <1usa@llenroc.ude.invalid>
Re: Need workaround for regex bug in 5.8.6 <sisyphus1@nomail.afraid.org>
Re: Need workaround for regex bug in 5.8.6 <1usa@llenroc.ude.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 10 Nov 2005 01:38:50 GMT
From: Samwyse <samwyse@gmail.com>
Subject: Re: FAQ 3.21 How can I compile my Perl program into byte code or C?
Message-Id: <Kwxcf.11737$7h7.10952@newssvr21.news.prodigy.com>
brian d foy wrote:
> In article <PZWaf.12351$dO2.4102@newssvr29.news.prodigy.net>, Samwyse
> <samwyse@gmail.com> wrote:
>
>
>>PerlFAQ Server wrote:
>>
>>>3.21: How can I compile my Perl program into byte code or C?
>>>
>>> (contributed by brian d foy)
>>>
>>> In general, you can't do this. There are some things that may work for
>>> your situation though. People usually ask this question because they
>>> want to distribute their works without giving away the source code, and
>>> most solutions trade disk space for convenience. You probably won't see
>>> much of a speed increase either, since most solutions simply bundle a
>>> Perl interpreter in the final product (but see "How can I make my Perl
>>> program run faster?").
>
>
>
>>Having just stumbled across a commercial application that does this,
I had intended for 'this' to refer to the 'things that may work for your
situation'. Since the first sentence of the answer says that you can't,
in general, compile to byte code, my intent was to discuss alternate
methods of obfuscation. I obviously didn't express myself very well
there; much apologies.
> That does what? Compiles your Perl program into C or byte code? Are you
> sure it's doing that and not something else?
It doesn't compile, it merely uses a Filter module to encrypt the source
code. Anyone with a copy of a valid license file could decrypt the
source without much trouble, but it does serve as a speed-bump for any
casual perusal.
> You mentioned ServerGraph, but I can't find any information about any
> product that does anything like compiling Perl. Indeed, it looks like
> its only mentions of Perl on it's website is in the Careers and Bios
> page.
Yes, there's not much on the website, but having played around with an
installed copy, I can say that it is written entirely in Perl. At
least, all of the non-GPL modules consist of two lines or comprehesible
text followed by a large blob of MIME-encoded data:
#!/usr/servergraph/bin/perl
use Crypt::License;
MFTUYJF%6hhtrKGHuytjkhKJY...
>>I
>>will point out that Crypt::License will perform some serious
>>obfuscation.
>
>
> That's not compiling though.
Again, I didn't intend to imply that it did.
>>Just mention the DCMA in your README file.
>
>
> That doesn't do much for most of the world :)
>
------------------------------
Date: Wed, 9 Nov 2005 15:10:17 -0800
From: James Marshall <jsm@jmarshall.com>
Subject: Need workaround for regex bug in 5.8.6
Message-Id: <20051109142502.Y33644@jmarshall.com>
I found a weird bug in Perl 5.8.6: If a variable in a CGI script (only)
is long enough, the script dies when it matches the variable against the
pattern /(.|ab)*/ . The critical length seems to vary by machine, or even
by data size or other environmental conditions-- memory or heap problem,
maybe? Here's an NPH CGI script that demonstrates the bug on my machine:
---------------------------------------
#!/usr/bin/perl
use strict ;
my($s)= ' ' x 15881 ; # 15880 is fine, but 15881 crashes
$s=~ /(.|ab)*/ ; # dies here with no warning
&HTTPdie('got here') ; # never gets here
# Die, outputting full HTTP response.
sub HTTPdie {
my($msg)= @_ ;
print <<EOF ;
HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/plain
$msg
EOF
exit ;
}
---------------------------------------
This bug doesn't happen if the script is run from the command line, no
matter how large $s is.
Have you seen this bug, and if so do you know a good workaround? Do you
know if it's fixed in 5.8.7? Even if so, I'd like a workaround for 5.8.6,
since the software will be used in many environments where the user has no
control over the Perl version.
I'm running this on Linux, kernel 2.6.11 (SuSE 9.3).
If it helps, running this script with Perl 5.8.4 results in a segmentation
fault, even when run from the command line. (The critical length of $s is
smaller.)
Thanks a lot for any help!
James
............................................................................
James Marshall james@jmarshall.com Berkeley, CA @}-'-,--
"Teach people what you know."
............................................................................
------------------------------
Date: Wed, 09 Nov 2005 23:42:55 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Need workaround for regex bug in 5.8.6
Message-Id: <Xns9709BE646EB6Dasu1cornelledu@127.0.0.1>
James Marshall <jsm@jmarshall.com> wrote in
news:20051109142502.Y33644@jmarshall.com:
> I found a weird bug in Perl 5.8.6:
I would not call it a bug. Rather, you are getting what you deserve.
...
> #!/usr/bin/perl
>
> use strict ;
>
> my($s)= ' ' x 15881 ; # 15880 is fine, but 15881 crashes
> $s=~ /(.|ab)*/ ; # dies here with no warning
> &HTTPdie('got here') ; # never gets here
Yeah, but did you ever read the server logs?
> This bug doesn't happen if the script is run from the command line, no
> matter how large $s is.
Now you are lying.
D:\Home\asu1\UseNet\clpmisc> cat r.pl
use strict;
use warnings;
my($s)= ' ' x 100000 ; # 15880 is fine, but 15881 crashes
$s=~ /(.|ab)*/ ; # dies here with no warning
D:\Home\asu1\UseNet\clpmisc> perl r.pl
Complex regular subexpression recursion limit (32766) exceeded at r.pl
line 5.
> Have you seen this bug, and if so do you know a good workaround?
It is not a bug, and the workaround is not to do something this stupid.
> ......................................................................
.
> .....
> James Marshall james@jmarshall.com Berkeley, CA
> @}-'-,--
> "Teach people what you know."
> ......................................................................
By the way, your signature is formatted incorrectly. It should be around
70 characters wide, and there should be a sig separator on the line
above it. A sig separator is dash-dash-space-newline.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Thu, 10 Nov 2005 12:01:06 +1100
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: Need workaround for regex bug in 5.8.6
Message-Id: <43729c0e$0$32020$afc38c87@news.optusnet.com.au>
"A. Sinan Unur"
.
.
>
> D:\Home\asu1\UseNet\clpmisc> cat r.pl
> use strict;
> use warnings;
>
> my($s)= ' ' x 100000 ; # 15880 is fine, but 15881 crashes
> $s=~ /(.|ab)*/ ; # dies here with no warning
>
> D:\Home\asu1\UseNet\clpmisc> perl r.pl
> Complex regular subexpression recursion limit (32766) exceeded at r.pl
> line 5.
>
I get the same on Windows 2000, perl5.8.4 - but on Windows 2000, perl5.8.7
all I get is an "Unknown software exception ..." WIndows popup - which in
the past has usually meant that the stack overflowed.
On linux, perl 5.8.7, it just outputs "Segmentation fault". Seems that
somewhere along the way, perl has lost the capability of handling the error,
and it's now left up to the operating system to deal with.
Something else has changed, too. On my Win32 box, using perl 5.8.7, the
"Unknown sopftware exception..." occurs with just 5207 spaces assigned to
$s. Using perl 5.8.4 (on the same box/os) there's no problem until at least
32767 spaces are assigned to $s (when the perl error occurs).
Cheers,
Rob
------------------------------
Date: Thu, 10 Nov 2005 01:19:09 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Need workaround for regex bug in 5.8.6
Message-Id: <Xns9709CEB53E8BEasu1cornelledu@127.0.0.1>
"Sisyphus" <sisyphus1@nomail.afraid.org> wrote in
news:43729c0e$0$32020$afc38c87@news.optusnet.com.au:
>
> "A. Sinan Unur"
> .
> .
>>
>> D:\Home\asu1\UseNet\clpmisc> cat r.pl
>> use strict;
>> use warnings;
>>
>> my($s)= ' ' x 100000 ; # 15880 is fine, but 15881 crashes
>> $s=~ /(.|ab)*/ ; # dies here with no warning
>>
>> D:\Home\asu1\UseNet\clpmisc> perl r.pl
>> Complex regular subexpression recursion limit (32766) exceeded at
>> r.pl line 5.
>>
>
> I get the same on Windows 2000, perl5.8.4 - but on Windows 2000,
> perl5.8.7 all I get is an "Unknown software exception ..." WIndows
> popup - which in the past has usually meant that the stack overflowed.
> On linux, perl 5.8.7, it just outputs "Segmentation fault". Seems that
> somewhere along the way, perl has lost the capability of handling the
> error, and it's now left up to the operating system to deal with.
>
> Something else has changed, too. On my Win32 box, using perl 5.8.7,
> the "Unknown sopftware exception..." occurs with just 5207 spaces
> assigned to $s. Using perl 5.8.4 (on the same box/os) there's no
> problem until at least 32767 spaces are assigned to $s (when the perl
> error occurs).
Interesting because I am using AS Perl 5.8.7 on Windows, and I cannot
observe the behavior.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8650
***************************************
