bug in Cygwin perl 5.6.1?

[Rhet Turnbull]

Gerrit P. Haase wrote:
>Hmmm, I'm still confused a little.  Isn't '010' as TRUE as '011'?

Yes, 010 is as true as 011. However, the $^S returns 0 or 1.  The example 
snippet shows the output of 3 separate reads of $^S.  I print the output as 
a string of zero's and ones just for simplicity -- it was just an easy way 
to show what the values of $^S were.

perl -e 'print $^S || 0;eval {print $^S || 0}; print $^S || 0;' decomposes 
to 3 statements:
1: print $^S || 0;
2: eval { print $^S || 0};
3: print $^S || 0;

= 3 separate times I print 1 or 0.  The only reason I did "|| 0" was in case 
$^S was undef I wanted to print 0 (perl prints nothing for an undef value) 
-- I really shouldn't have done that since in fact it masked another bug -- 
see statement below. The reason perl is buggy for this example is that after 
the eval (statement #2 above) $^S should have a value of 0 but instead it 
has a value of 1.  $^S should be 1 ONLY inside an eval.  Also, I didn't 
catch it (because I had the || 0 above) but the first read of $^S is also 
buggy -- it returns undef when it should be 0.  On Cygwin perl 5.6.1:

$ perl -e 'print "undef" if not defined $^S'
undef

$^S should be 0 not undef in that example.

So, the effect of having $^S be 1 outside an eval is that a custom DIE or 
WARN handler cannot determine if it's inside an eval or not and this is 
important to know.

Hope that helps. Regards,

--Rhet

----Original Message Follows----
From: "Gerrit P. Haase" <gerrit@familiehaase.de>
Reply-To: gerrit@familiehaase.de
To: "Rhet Turnbull" <RhetTbull@hotmail.com>,              
<cygwin@cygwin.com>
Subject: Re: bug in Cygwin perl 5.6.1?
Date: Sun, 3 Feb 2002 22:03:36 +0100

Am 2 Feb 2002 um 17:58 hat Rhet Turnbull geschrieben:

 >Gerrit P. Haase wrote:
 >> Why?  Where is docu about this?
 >
 >The perl documentation for $^S in the perlvar manpage states:
 >
 >$^S     Current state of the interpreter.  Undefined if
 >        parsing of the current module/eval is not finished
 >        (may happen in $SIG{__DIE__} and $SIG{__WARN__}
 >        handlers).  True if inside an eval(), otherwise
 >        false.
 >
 >The "True if inside an eval(), otherwise false" is what I was getting at.  
I

Previous mail:

 >>>There seems to be a bug in Cygwin's perl (5.6.1). The
 >>>following code:
 >>>
 >>>perl -e 'print $^S || 0;eval {print $^S || 0}; print
 >>>$^S || 0;'
 >>>
 >>>should produce '010'

 >ran into this since I was writing a custom SIG{__DIE__} handler (which 
needs
 >to know if you're inside an eval where die is an exception catching
 >mechanism or in normal code where die means to exit with error.)  The bug 
is
 >that after executing an eval(), $^S stays true even though it should be
 >false outside the scope of the eval.

Hmmm, I'm still confused a little.  Isn't '010' as TRUE as '011'?

 >I reported this to perlbug and they've acknowledged that it's a known bug
 >that will be fixed in next release.


Thanks,

Gerrit--
=^..^=



_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/