Re: BUG: strange behaviour with 'use open IN = :byte'

[Rafael Garcia-Suarez]

On 17/09/2007, David Cantrell [EMAIL PROTECTED] wrote:
 On Sat, Sep 15, 2007 at 02:44:27PM +0200, [EMAIL PROTECTED] wrote:

  If I run this script:
  #!/usr/bin/perl
  use open IN  = :byte;

If you use open IN = :bytes, that works.

What happens is that perl tries to load PerlIO::byte, in order to read
constant.pm. But this PerlIO layer isn't found, hence the (suboptimal
and buggy) error message.

  use constant A = 1;
 
  on a MacBook Pro (Intel) with perl version 5.8.6 (the pre-installed) I
  get this error:
Can't locate constant.pm in @INC  ...
 
  if I change the line to:
  use open IN  = :encoding(UTF16-BE);
 
  I get this error:
Unrecognized character \xE0 at /System/Library/Perl/5.8.6/constant.pm 
  line 1.

 I get similar with 5.8.7 and 5.9.5 on NetBSD/Alpha, and 5.10.0 patch 31863
 on Solaris/SPARC.  Congratulations, it looks like you've found a bug in
 perl!

  In both cases:
  If I swap the lines, everything runs smoothly.

 Same here. I've CCed p5p on this mail.

 --
 David Cantrell | A machine for turning tea into grumpiness

 There's a hole in my bucket, dear Liza, dear Liza.
 WHAT MAKES YOU SAY THERE IS A HOLE IN YOUR BUCKET?

Re: checking that non-UNIX platforms don't lag in their Configure variables

[Rafael Garcia-Suarez]

Jarkko Hietaniemi wrote:
 The attached script, suitable for Porting/, suitable for both blead
 and maint, helps in the battle of keeping the non-UNIX platforms up
 to date in their knowledge of Configure variables.  Run it at the
 top level directory and it will tell its best guess as to which of
 those variables are missing in various places.  The task of adding
 d_foo='undef' and the like all over the place is left as a manual
 exercise.

Thanks, applied.

And indeed it detects quite a few missing symbols, for epoc,
Netware, symbian (!), plan9 and windows CE.

Also, uconfig.sh probably needs to be updated, although I'm not
100% sure how to do this properly.

Re: $^E bug and perl 5.8.0

[Rafael Garcia-Suarez]

Chris Nandor wrote:

 (For the porters: the bug is that this:
 
   % perl -le '$^E = -1728; print $^E+0 for 0,1'
 
 Should return this:
 
   -1728
   -1728
 
 But in some cases, returns this:
 
   -1728
   22
 
 Odd.)

What does
perl -le 'print $!=22'
on your system ?
Can you reproduce this bug with $! in place of $^E ?

Re: $^E bug and perl 5.8.0

[Rafael Garcia-Suarez]

Chris Nandor wrote:

 At 16:39 +0100 2003.11.19, Rafael Garcia-Suarez wrote:
 What does
  perl -le 'print $!=22'
 on your system ?
 
 22.

Hmm, weird -- on my Linux 2.2 it prints correctly Invalid argument.
I wanted to know what was this errno corresponding to.
(but I can't reproduce your bug either)

Try this naive patch :

--- mg.c.orig   Wed Nov 19 16:41:47 2003
+++ mg.cWed Nov 19 16:44:14 2003
@@ -623,8 +623,12 @@ Perl_magic_get(pTHX_ SV *sv, MAGIC *mg)
  SetLastError(dwErr);
 }
 #else
-sv_setnv(sv, (NV)errno);
-sv_setpv(sv, errno ? Strerror(errno) : );
+{
+int saveerrno = errno;
+sv_setnv(sv, (NV)errno);
+sv_setpv(sv, errno ? Strerror(errno) : );
+errno = saveerrno;
+}
 #endif
 #endif
 #endif

Re: $^E bug and perl 5.8.0

[Rafael Garcia-Suarez]

Dan Sugalski wrote:
 
 Given that on Unix systems $^E and $! are identical, and that $! is
 directly tied to errno, this certainly isn't surprising. Anything that
 afects errno (like, say, IO) may then affect $! and $^E identically.(And
 $!/$^E non-indentically on systems where they're separate)

On Unix the implementation of $! and $^E should be the same -- that's fixed
by the patch I sent (although a more proper version would refactor it (and
add tests:))

 Basically you're using a variable that can be affected by external things
 in a way that pretty much guarantees that external things will be
 happening. That it changes isn't much of a surprise. ($!/$^E may get
 modified by some signal handlers too, depending on what you do, so there's
 not even any guarantee that $^E = 42; $^E++; will end up with $^E set to
 43.

Using the Mac OS X equivalent of truss/strace might help to find out
why errno changes there.

Re: $^E bug and perl 5.8.0

[Rafael Garcia-Suarez]

 Try this naive patch :
 
 --- mg.c.orig Wed Nov 19 16:41:47 2003
 +++ mg.c  Wed Nov 19 16:44:14 2003

Now applied as #21743 to bleadperl.
Considering the intricacies of the #ifdef forest in there,
I left out refactoring with $! for now.

Re: Crash reading $|

[Rafael Garcia-Suarez]

Mark Alldritt wrote in perl.macosx :
 
 I'm seeing a crash reading $| in the following code snippet:
 
 local *STDOUT; 
 
 my $copy = $|; # -- crashes here

This bug will be fixed in 5.9.0 and eventually in 5.8.1 if it's picked
up for the next release candidate.

 I'm reading $| in some code that does not know if local *STDOUT has happened
 or not.  Can anyone think of a way to work around this?

Test for fileno(STDOUT) to see whether it's been undefined.
On my linux :

$ cat x 
#!perl -l
print STDERR -,fileno(STDOUT),-;
local *STDOUT;
print STDERR -,fileno(STDOUT),-;

$ perl x 
-1-
--

HTH.

-- 
Ulcers is not *NIX

Re: unix or mac-style text files?

[Rafael Garcia-Suarez]

Chris Nandor [EMAIL PROTECTED] wrote:
 
 That shouldn't work.  By the time you get to it in the script, if you have a 
 #! line, then the entire script is one long comment, and the use() line 
 won't ever be executed.

That would be an argument for allowing -M/-m on the #! line.