Path: utzoo!attcan!uunet!peregrine!elroy.jpl.nasa.gov!sdd.hp.com!think.com!paperboy!hsdndev!husc6!genrad!rep
From: rep@genrad.com (Pete Peterson)
Newsgroups: comp.lang.perl
Subject: perl bugs in pl41
Keywords: bugs perl41
Message-ID: <39929@genrad.UUCP>
Date: 5 Dec 90 20:49:35 GMT
Sender: news@genrad.UUCP
Lines: 107


 The following bugs all exist in perl 3.41 on all platforms unless otherwise
noted.

---------------------------------------------------------------------------
There is a bug which appears when grep is used with a filetest or
expression including a filetest as the condition and a wildcard expansion
as the list.  There may be other manifestations, but this was the simplest
one I could generate.

Trivial Example:

perl -we '$,="\n";print grep(-d,<*>),"\n";'

  This should print a list of the directories in the current directory.
  It actually prints error messages like the following and also produces
  incorrect output (the latter, even if -w be omitted):

  "Use of uninitialized variable at /tmp/perl-ea03382 line 1, <_GEN_0> line 5."

  You get one message for each file in the wildcard expansion.

Workaround:

perl -we '$,="\n";print grep(-d,@bug=<*>),"\n";'

  This works as expected, with -w giving only the warning about the
  variable which appears only once.

---------------------------------------------------------------------------

We have discovered a bug (on all platforms) wherein a postincremented
string variable used as a file handle works improperly; namely, it uses the
incremented value as the filehandle.  I reported this bug by mail last
August, but never got any feedback.

Simplified example:
    This script should open file "foo" with filehandle "OUT1" and should
    therefore print "OUT1".  It actually prints "OUT2".

#!/usr/local/perl
$FILE="OUT1";
open($FILE++, ">foo");
print "OUT1\n" if -e OUT1;
print "OUT2\n" if -e OUT2;

---------------------------------------------------------------------------

There is a bug on the pmax (decstation) which appears to relate to integers
with the MSB set.  The following works fine on suns and vaxes but fails in
different ways with perl 3/18 and perl 3/41 on the pmaxen:

printf (" %x, %x, %x, %x\n", 0xffffffff, 0xf0000000, 0x81234567, ~0xffff);
printf (" %x, %x, %x\n", 0xfffffff<<4, 15 << 28, ~1);
$a = 0xffff0000 & 7; $b = 15 << 28 & 7; print " a is $a; b is $b\n";

Should print (and does except on pmax):
 ffffffff, f0000000, 81234567, ffff0000
 fffffff0, f0000000, fffffffe
 a is 0; b is 0
--------------------
In perl41 on pmax, you get:
 7fffffff, 7fffffff, 7fffffff, 7fffffff
 fffffff0, f0000000, 7fffffff
 a is 7; b is 0
--------------------
In perl18 on pmax, you get:
 ffffffff, f0000000, 81234567, 7fffffff
 fffffff0, f0000000, 7fffffff
 a is 0; b is 0

This problem can be worked around by editing config.sh, at the end of
running Configure, to make "d_castneg='undef'".

---------------------------------------------------------------------------

There is an additional idiosyncrasy which relates to <globstring>
expansions in recursive subroutine calls.  I don't have a nice compact
example handy, but it appears in things like


sub recurse {
	local $foo;
	.
	.
	foreach $foo (<xxx.yy*>) {
		.
		.
		do recurse(aaa,bbb);
		.
		.
		}
	.
	.
	}

What appears to happen is that when the subroutine exits up to the previous
instance of itself, the $foo at that level doesn't get the next list
element of the glob operation.

Replacing "foreach $foo (<xxx.yy*>)" with @ary=<xxx.yy*>; foreach $foo (@ary)"
(with a "local @ary;" in the subroutine) appears to work as expected.

---------------------------------------------------------------------------
	pete peterson
	rep@genrad.com
	{decvax,linus,wjh12,mit-eddie,masscomp}!genrad!rep