[perl #2744] [BUG] perlcc bugs (about seven or eight of them)
[EMAIL PROTECTED] - Tue Mar 28 03:39:04 2000]:
% cat bad
#!/usr/bin/perl
sub fn {
local $key = I am the key!;
print Have: $key\n;
}
fn();
% perl bad
Have: I am the key!
% perlcc bad
Compiling bad:
ERROR: 'bad' does not have a proper extension!
This silly behavior appears to have been fixed. 5.6.2 and 5.8.6 both
take perlcc bad fine.
I can also compile the program. 5.6.2 and 5.8.0 compile with no
problem. 5.8.6 warns:
0 windhund ~/tmp$ perlcc bad
pccM2diy.c: In function `perl_init_':
pccM2diy.c:1205: warning: this decimal constant is unsigned only in ISO C90
bleadperl is downright boisterous. Its output is attached. I'm leaving
this ticket open because of all the warnings.
perlcc.out
Description: Binary data
[perl #2741] [BUG] version checking doesn't work per apparent docs
[EMAIL PROTECTED] - Tue Mar 28 03:38:58 2000]: From perldata: A literal of the form `v1.20.300.4000' is parsed as a string composed of characters with the specified ordinals. Such literals are accepted by both `require' and `use' for doing a version check. This is not true, however. Witness: % perl -MIO::File -le 'print IO::File::-VERSION 1.08 % perl -e 'use IO::File 1.08' % perl -e 'use IO::File v1.08' Octal number in vector unsupported at -e line 1, at end of line BEGIN not safe after errors--compilation aborted at -e line 1. # vector? qu'est-ce que c'est qu'un vector? # did I vec() something for select()? % perl -e 'use IO::File 1.8' IO::File version 1.8 required--this is only version 1.08 at -e line 1. BEGIN failed--compilation aborted at -e line 1. % perl -e 'use IO::File v1.8' % perl -e 'use IO::File 1.8.2' % perl -e 'use IO::File v1.8.2' % perl -e 'use IO::File 1.9.2.20' % perl -e 'use IO::File v1.9.2.20' % perl -e 'use IO::File 1.9.9' % perl -e 'use IO::File 1.9..999' % perl -e 'use IO::File v1.9.9' % perl -e 'use IO::File v1.9..999' ### Ick ick ick! Something sure smells pretty icthy around here. # And here's some naive stuff. Remember: version were always numbers # before. So one expects numbers to continue to work. But they don't. # And produce very odd msgs. % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION 1.8' 0 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION v1.8' 1 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION 1.8' 1 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION v1.8' 0 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION == 1.08' 1 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION == v1.08' Octal number in vector unsupported at -e line 1, at end of line Execution of -e aborted due to compilation errors. # octal huh? % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION == v1.80' Octal number in vector unsupported at -e line 1, at end of line Execution of -e aborted due to compilation errors. % perl -MIO::File -we 'printf %d\n, IO::File::-VERSION == v1.80' Argument ^AP isn't numeric in numeric eq (==) at -e line 1. 0 # That's disgusting. Run it through uncontrol! v1.2.3 style version strings are being phased out and should be replaced by the various options presented by version.pm. All the above now works in 5.8.6 with the exception of the final Argument ^AP isn't numeric warning which is still there. As version strings are going bye-bye will that ever be fixed?
[perl #2900] B::CC cannot sort
[EMAIL PROTECTED] - Thu Mar 30 11:30:55 2000]:
This simple program:
for $k (sort { length $ENV{$b} = length $ENV{$a} } keys %ENV) {
print $k=$ENV{$k}\n;
}
Under B::Bytecode, produces correct results, then SEGVs
Now working in 5.8.6.
Under B::C, produces correct results, then exits correctly.
Still working in 5.8.6.
Under B::CC, produces no results, but goes into recursive
doom in the sort, eventually SEGVing for lack of memory
in stack death.
$ perlcc -O foo
/sw/bin/perlcc: foo did not compile, which can't happen:
Can't locate object method _save_common_middle via package B::FAKEOP
at /sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/B/C.pm line 389.
CHECK failed--call queue aborted.
Same for bleadperl.
[perl #2898] some reports on byteloaded modules
[EMAIL PROTECTED] - Thu Mar 30 10:31:39 2000]:
You can kind create byteloaded modules and use them like
regular ones.
Can we compile it?
% perlcc -b -o /tmp/Carp.pm `perl -MCarp -le 'print
$INC{Carp.pm}'`
[random noises deleted]
[Exit 0]
That would be a yes. Can we uncompile it?
% perl -MO=Deparse /tmp/Carp.pm
/tmp/Carp.pm syntax OK
% perl -MO=Deparse,-p /tmp/Carp.pm
/tmp/Carp.pm syntax OK
5.8.6 and blead both fail with:
0 windhund ~/tmp$ perl -MO=Deparse Carp.pm
Can't locate object method sibling via package B::NULL at
/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/B/Deparse.pm line 1188.
CHECK failed--call queue aborted.
Well, yes and no. We can uncompile other things. This one
seems unwillling, however.
May we run it?
% perl /tmp/Carp.pm
[Exit 0]
Yes, we can! Can we do anything cool with it?
% perl -e 'require /tmp/Carp.pm; Carp::carp(wow)'
wow at -e line 1
require /tmp/Carp.pm called at -e line 1
Not a CODE reference at -e line 1.
perl in free(): warning: chunk is already free.
Segmentation fault
Exit 139
This now works in 5.8.6 and blead.
0 windhund ~/tmp$ perl -I. -wle 'use Carp; print $INC{Carp.pm};
carp(wow)'Carp.pm
wow at -e line 1
[perl #4687] UNIVERSAL::isa can report incorrect results
[EMAIL PROTECTED] - Mon Nov 13 00:10:45 2000]: If one package (say, Bar) is declared to be a subclass of another package (say, Foo) by assigning to the first package's @ISA array, UNIVERSAL::isa denies that Bar is a subclass of Foo unless Foo's stash has been created. This prints nothing: perl -le '@Bar::ISA = Foo; print Bar-isa(Foo)' This prints 1: perl -le '@Bar::ISA = Foo; $Foo::var = 1; print Bar-isa(Foo)' This bug is still present in 5.8.6 and bleadperl.
[perl #4990] CORE::GLOBAL support broken in 5.6.0
[EMAIL PROTECTED] - Wed Dec 20 04:02:32 2000]: Importing subroutines into the CORE::GLOBAL package does not work. The perlsub documentation makes reference to the File::DosGlob module. I've tested that the GLOBAL_glob export option for this module does not work. Although I don't have a 5.6.0 to check with, 5.6.2 seems to work as advertised. $ perl5.6.2 -dwe ' use File::DosGlob 'GLOBAL_glob'; print glob *' Default die handler restored. Loading DB routines from perl5db.pl version 1.07 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): use File::DosGlob GLOBAL_glob; print glob * DB1 As does 5.5.4, 5.8.6 and bleadperl.
[perl #5070] Inconsistent arithmetic with % and * operators
[EMAIL PROTECTED] - Thu Jan 04 10:10:18 2001]: # The following complete four-line perl script produces unexpected # results on my machine. The multiplication in the second line of # code below produces a negative result where a positive number is # expected, presumably because an integer multiplication was used # internally where a floating point operation was needed. If the # expression is broken up and evaluated piece by piece then the # correct result is produced (line 4). (The difference between the two # results is, naturally, 2**32.) The same results were produced under # perl v5.6.0. my ($p, $x, $y) = (65537, 64645, 34463); print (($x % $p) * ($y % $p), \n); # produces -2067106661 (incorrect) my ($a, $b) = ($x % $p, $y % $p); print $a * $b, \n; # produces 2227860635 (correct) Confirmed broken in 5.6.2. Confirmed fixed in 5.8.0. 0 windhund ~/tmp$ perl5.6.2 test -2067106661 2227860635 0 windhund ~/tmp$ perl5.5.4 test -2067106661 2227860635 0 windhund ~/tmp$ perl5.8.6 test 2227860635 2227860635 0 windhund ~/tmp$ perl5.8.0 test 2227860635 2227860635 0 windhund ~/tmp$ perl5.8.1 test 2227860635 2227860635
[perl #5087] used only once warning for lexicals?
[EMAIL PROTECTED] - Fri Jan 05 01:38:47 2001]: Maybe there's a reason for it, but... ~ 12:35:18$ perl -wce '$count = 1;' Name main::count used only once: possible typo at -e line 1. -e syntax OK BUT... ~ 12:35:52$ perl -wce 'my $count = 1;' -e syntax OK Shouldn't that warning be raised, regardless of scope? I agree. In fact the argument for the warning is even stronger for a lexical. A global seen only once... well maybe some other package grabs at it. But a lexical declared but never used is useless. About the only counter argument I can see is that issuing the warning for lexicals will cause a lot of existing code to start yelping. But that's what warnings are for. I for one would like to know about unused lexicals.
[perl #36621] /\pL/ breaks -0
[EMAIL PROTECTED] - Thu Jul 21 10:31:16 2005]: While playing perlgolf I noticed a strange thing: perl -0e print while $_=pop||,/\pL/ foo This first prints foo (that's okay). But then if you type bar, it immediately outputs bar. It shouldn't do so, because should read until \0 (notice the -0 option), not until \n. Just try /\w/ instead of /\pL/. Confirmed a bug in 5.8.0. Confirmed fixed in 5.8.6 and bleadperl. Thank you for your bug reports but please try a newer verison of Perl before reporting bugs.
[perl #17765] UTF-8 in the debugger
[EMAIL PROTECTED] - Sun Jul 17 12:00:05 2005]: The problem is not the wide character in print warning. The problem is that $_ is not 'o' as it is when run outside the debugger. Seems to be fixed in 5.8.7 and bleed. Confirmed and resolved.
[perl #22312] Another self-modifyingloop bug
[EMAIL PROTECTED] - Sat May 24 14:07:05 2003]: perl -e '[EMAIL PROTECTED]($_+=0)[EMAIL PROTECTED]/\B./g for 1100..2000' Segmentation fault (core dumped) A bit different from the normal ones which mostly involve modifying a for loop variable. map usually can take these abuses. Confirmed segfaulting in 5.8.6 and [EMAIL PROTECTED] 5.6.2, 5.5.4 and 5.4.5 don't segfault.
[perl #22336] shellwords.pl is not Shell compatible
[EMAIL PROTECTED] - Tue May 27 01:34:44 2003]: Perl still contains a Perl 4 library, that purports to emulate the way the Shell parses a command. But it can't handle backquotes or variable interpolation. And it gets backslash wrong. Could you provide an example? I can't find a case where shellwords deviates from bash's behavior. Also I don't think shellwords promises to do variable interpolation. In fact, it doesn't promise much at all. Perl make http://dapfy.bei.t-online.de/make.pl/ now contains a similar function shellparse, which corrects these bugs. Welcome to use it as you please, if you give me the credit. Unfortunately that URL is unavailable.
[perl #23666] Core dump on big regex
[EMAIL PROTECTED] - Sat Aug 30 14:33:01 2003]: perl -wle '(1x5683)=~ /^(11+)\1+$/' works ok perl -wle '(1x 9973)=~ /^(11+)\1+$/' Segmentation fault (core dumped) ulimit -a core file size (blocks) unlimited data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes)unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 1048576 cpu time (seconds) unlimited max user processes 6143 virtual memory (kbytes) unlimited I can't reproduce with 5.8.0, 5.8.6 or bleadperl on OS X. I can reproduce on Debian 5.8.4 but I need to crank up the size a bit. $ perl -wle '(1x 19973)=~ /^(11+)\1+$/' Segmentation fault I don't have a newer Perl on Linux to try out.
[perl #30377] sort SUBNAME LIST
[EMAIL PROTECTED] - Sat Jun 19 11:06:22 2004]:
perl -wle 'sub foo { return 1..5} print sort foo(8)'
8
while a bit annoying (I wanted to sort the result of foo applied to
8),
this is actually what is documented as the
sort SUBNAME LIST
form of sort. foo is the subname and there is one value to be sorted:
8
5.6.1 this will reportedly behaves the same (I don't have a 5.6.1
anymore)
5.6.2 does.
More interesting:
perl -wle 'sub foo { return 1..5} print sort(foo(8))'
12345
I see nothing in the sort docs that would make me expect a change in
behaviour here by just adding parenthesis.
(Nor does it in real indirect object cases like print(STDERR foo))
I don't think print is the right analogy here. map and grep have the
closest interface to sort.
So you get an extra warning and it behaves the same as without the
parenthesis. For both things I think that the 5.6.1 behaviour was the
right one. In fact, I'd also have expected the unquoted string warning
for the case without parenthesis, but it seems 5.6.1 doesn't do that.
If you don't agree with me that these are bugs, this behaviour should
at
least be documented.
I don't know if its a bug so much as an ambiguity made espcially tricky
by its reliance on whitespace to DWIM. Changing the behavior to this
would seem to be more like folks would expect.
sort foo(8) # call foo(8) and hand the results to sort
sort foo (8) # use foo() as the sort routine to sort the list (8).
And before the Cfunc (arg) style camp objects, its not working
properly for that style now anyway.
[perl #29230] Class::Struct, accessor overrides not called from constructor
[rhesa - Wed Apr 28 11:12:56 2004]:
Class::Struct allows you to override the accessors it creates, but it
doesn't call them in its constructor.
In other words,
$struct-field('blah');
calls my override, but
$struct = structure-new('field' = 'blah');
doesn't. Class::Struct simply does
$r-{'field'} = $init{'field'}
but it would be more useful if it did
$r-field($init{'field'})
Sounds like a valid complaint to me. Example 2 in the docs demonstrates
overriding Class::Struct accessors and the constructor should follow suit.
Pumpkings, there's a patch with this ticket to fix this.
[perl #8765] non-english letters and non-greedy subpatterns, like this one
[RT_System - Mon Mar 04 21:30:58 2002]: This is an alternative and it confirmes the bug in 5.6.1: % /usr/local/perl-5.6.1/bin/perl -le ' $_ = \xF9 \xF6; print /\xF9\s+?\xF6/ ? ok : not ok; ' not ok The bug is fixed in perl-5.7.3 and the fix will be in 5.8.0 and 5.6.2. Confirmed broken in 5.6.2. $ perl5.6.2 -le ' $_ = \xF9 \xF6; print /\xF9\s+?\xF6/ ? ok : not ok; ' not ok Confirmed fixed in 5.8.6. $ perl -le ' $_ = \xF9 \xF6; print /\xF9\s+?\xF6/ ? ok : not ok; ' ok Resolved.
[perl #36514] Add curl support to CPAN.pm
[EMAIL PROTECTED] - Tue Jul 12 03:24:42 2005]: It would be nice if CPAN.pm supported curl as a download method. Particularly because OS X ships with *none* of the currently handled methods (wget, lynx, ncftp*). Well that was surprisingly easy. Patch attached. It makes curl the first choice since its the most capable of all the options handling pretty much every schema type you'd ever want short of rsync. (HTTP, HTTPS, FTP, FTPS, GOPHER, DICT, TELNET, LDAP or FILE) CPAN_curl.patch Description: Binary data
[perl #4207] Deparse generating unparsable code.
[abigail - Sat Sep 02 03:39:24 2000]:
$ perl -we '$@ = [foo\n]; print [EMAIL PROTECTED]@[EMAIL PROTECTED]'
foo
$ perl -MO=Deparse -we '$@ = [foo\n]; print [EMAIL PROTECTED]@[EMAIL
PROTECTED]'
$@ = [foo\n];
print ${$@;[EMAIL PROTECTED]@;}];
-e syntax OK
$ perl -MO=Deparse -we '$@ = [foo\n]; print [EMAIL PROTECTED]@[EMAIL
PROTECTED]' |
perl
-e syntax OK
Array found where operator expected at - line 2, at end of line
(Missing operator before ?)
syntax error at - line 2, near @$@;
Execution of - aborted due to compilation errors.
$
Confirmed broken in 5.6.2.
$ perl5.6.2 -MO=Deparse -we '$@ = [foo\n]; print [EMAIL PROTECTED]@[EMAIL
PROTECTED]' |
perl5.6.2
-e syntax OK
Array found where operator expected at - line 2, at end of line
(Missing operator before ?)
syntax error at - line 2, near @$@;
Execution of - aborted due to compilation errors.
Confirmed fixed in 5.8.6.
$ perl5.8.6 -MO=Deparse -we '$@ = [foo\n]; print [EMAIL PROTECTED]@[EMAIL
PROTECTED]' |
perl5.8.6
-e syntax OK
foo
[perl #25145] Storable segfaults with B::Deparse + overload + cyclic structures
[EMAIL PROTECTED] - Tue Jan 20 02:14:31 2004]: I've attached the fix, and included the segfault protection afforded by the previous patch (it now uses the nearby CROAK code path). I'm sure that the problem will apply to at least one other piece of the code so when I stumble across it I'll add the tests to t/just_plain_nasty.t :-) Looks like this patch was applied to Storable 2.10 but the bug left open. Resolved.
[perl #7067] Errno error in IO::Socket::INET
[EMAIL PROTECTED] - Thu May 31 05:01:54 2001]: #!/usr/bin/perl my $addr = 192.168.2.2; # or any non-reachable address my $port = 5010; use IO::Socket; my $sock = IO::Socket::INET-new(PeerAddr=$addr, PeerPort=$port, Proto='tcp', Timeout = 3); print Connect failed: [EMAIL PROTECTED] unless ($sock); produces: Connect failed: IO::Socket::INET: Digging into the code (IO::Socket::INET line 169), I see: return _error($sock,$!) unless @raddr; (i.e. set $@ to IO::Socket::INET: $! and return undef). However, in the case of a failed IO::Socket::connect() call (i.e. bad address, failed connect(2), or timeout), the connect call dies via 'croak' in an eval, so $@ (not $!) contains the error message. I changed the line to return _error($sock, $! ? $! : $@) unless @raddr; , which seems to work. I am unable to reproduce this problem with 5.4.5, 5.5.3, 5.6.2 or 5.8.6 on OS X. I don't have a Linux machine handy with a 5.6.x to reproduce. So I can't confirm that the bug is fixed, but there does seem to be code in IO::Socket::INET to take into account both $! and $@ in each error. Anyone care to confirm?
[perl #10076] RC3 ineffective ext/SDBM_File/SDBM_File.c compiler silencing
[w.briscoe - Mon Jul 15 17:29:27 2002]:
I got the following diagnostic:
cl -c [...] SDBM_File.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
SDBM_File.c
SDBM_File.c(296) : warning C4700: local variable 'key' used without having
been initialized
The line in question is:
datum_key key = key; /* never used - silence picky compilers. */
The following change works for me and is likely to be portable:
C:\perl-5.8.0-RC3\ext\SDBM_File \wfb\bin\diff -c 0SDBM_File.xs
SDBM_File.xs
*** 0SDBM_File.xs Sat Jun 1 18:03:10 2002
--- SDBM_File.xsMon Jul 15 22:23:18 2002
***
*** 119,125
datum_key
sdbm_NEXTKEY(db, key)
SDBM_File db
! datum_key key = key; /* never used - silence picky
compilers. */
int
sdbm_error(db)
--- 119,125
datum_key
sdbm_NEXTKEY(db, key)
SDBM_File db
! datum_key key = {0}; /* never used - silence picky
compilers. */
int
sdbm_error(db)
C:\perl-5.8.0-RC3\ext\SDBM_File
The following looks better but may fail in circumstances of which I
know naught. (I have not found the .xs to .c file mapping mechanism.):
C:\perl-5.8.0-RC3\ext\SDBM_File \wfb\bin\diff -c 0SDBM_File.xs
SDBM_File.xs
*** 0SDBM_File.xs Sat Jun 1 18:03:10 2002
--- SDBM_File.xsMon Jul 15 22:44:50 2002
***
*** 119,125
datum_key
sdbm_NEXTKEY(db, key)
SDBM_File db
- datum_key key = key; /* never used - silence picky
compilers. */
int
sdbm_error(db)
--- 119,124
Patch 24994 touches this line. Steve, were you aware of this bug?
http://public.activestate.com/cgi-bin/perlbrowse?patch=24994
[perl #7565] Thread safe queues on SMP kernel
When run using 5.8.6 and ithreads perl thinks for a while and then sez: $ perl ~/tmp/test A thread exited while 4 threads were running. So this looks like an issue in Thread::Queue and not 5.005threads. Unless the sample code is not sane, but I don't know threads well enough to evaluate that.
[perl #9720] threads::shared and perlthrtut: Update to give example of object
[EMAIL PROTECTED] - Sun Jun 23 02:21:24 2002]: Having tried to share objects by writing stuff along the lines: my $a : shared = new FOOBAR; It took a posting to comp.lang.perl.misc before I realised the error of my ways: my $a = new FOOBAR; share($a); I don't think the threads::shared and perlthrtut docs make this clear enough - folks coming to ithreads from Java etc are going to finds things a bit odd to begin with. SOLUTION: More examples in the docs please, esp. regarding object sharing. Also maybe trim down some of the general threading info in perlthrtut with more focus on perl threads and how to use them idiomatically. threads::shared and perlthrtut still lacks this additional documentation.
[perl #18535] Problems compiling threaded perl 5.8.0 on OS/390
[EMAIL PROTECTED] - Wed Nov 20 08:26:56 2002]:
I am following the steps in the README.os390 file and I have applied
the
fix to makedepend.SH (provided by Peter Prymmer) with regard to the
unwanted removal of the last #endif statement in perly.c as below:
--- makedepend.SH.orig Mon Nov 29 18:05:08 1999
+++ makedepend.SHMon Nov 29 18:10:43 1999
@@ -130,6 +130,9 @@
-e 's|\\$||' \
-e p \
-e '}' ) UU/$file.c
+if [ $osname = os390 -a $file = perly.c ]; then
+$echo '#endif' UU/$file.c
+fi
$cppstdin $finc -I. $cppflags $cppminus UU/$file.c |
$sed \
-e '/^#.*stdin/d' \
End of Patch.
and having made this fix the Configure and the make depend steps
complete
cleanly with no warnings or errors.
This patch appears to have made it into makedepend.SH.
However, when performing the actual make step I am encountering the
following error when compiling perly.c
ERROR CCN3276 ./perly.c:128 Syntax error: possible missing ')'?
I decided to turn on the -V flag of the c89 compiler and this
identified
the error as follows:
125 |#define POSTINC 315
| 48923
126 |#define POSTDEC 316
| 48924
127 |#define ARROW 317
| 48925
128 |extern int yychar, yyerrflag;
| 48926
128 +extern int (my_perl-Iyychar), (my_perl-Iyyerrflag);
+ 48926
===
..a..
*=ERROR=== a - CCN3276 Syntax error: possible missing ')'?
129 |#if YYDEBUG
| 48927
130 |yyTypedRules yyRules[] = {
| 48928
131 |{ 00: %01 00, 0},
| 48929
132 |{ %01: %07 %12, 1},
| 48930
This appears to be a problem with the actual C code itself.
I have tried compiling perl with exactly the same options but without
enabling thread support and it compiles and installs with no problems.
Are you able to compile recent stable perls in os390 with thread support
enabled?
[perl #18961] Problem compiling DBD::Pg with thread support in 5.8 on Mac OS 10.2.2
[radknee - Sun Dec 08 09:15:16 2002]:
Using CPAN I did 'install DBD::PG'. Config went ok, but make produced the
errors below. When I recompiled perl without threads make went ok.
[systame1:local/src/DBD-Pg-1.13] randy% make
cc -c -I/usr/local/pgsql/include
-I/Library/Perl/darwin-thread-multi/auto/DBI -pipe -fno-common
-no-cpp-precomp -fno-strict-aliasing -O3 -DVERSION=\1.13\
-DXS_VERSION=\1.13\ -I/Library/Perl/darwin-thread-multi/CORE Pg.c
cc -c -I/usr/local/pgsql/include
-I/Library/Perl/darwin-thread-multi/auto/DBI -pipe -fno-common
-no-cpp-precomp -fno-strict-aliasing -O3 -DVERSION=\1.13\
-DXS_VERSION=\1.13\ -I/Library/Perl/darwin-thread-multi/CORE
dbdimp.c
dbdimp.c: In function `dbd_bind_ph':
dbdimp.c:1041: internal error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://developer.apple.com/bugreporter for instructions.
{standard input}:1407:FATAL:.abort detected. Assembly stopping.
make: *** [dbdimp.o] Error 1
I think your C compiler crashed, not perl. I'd report the issue to
Apple, as recommended by the error.
Rejecting this ticket.
[perl #23965] Data::Dumper + threads + recursion = segfault
[davem - Tue Sep 23 17:09:43 2003]: On Mon, Sep 22, 2003 at 05:01:19PM -, David Buckley wrote: use threads; use threads::shared; use Data::Dumper; our $a : shared; $a = \$a; print Data::Dumper::Dumper( $a ); This produces a short pause, then a segfault. The segfault is due to stack or memory exhaustion caused by infinite recursion. The problem is due to the 'proxy' per-thread variables failing to detect a loop caused by mg_get(). This is still an issue in [EMAIL PROTECTED]
[perl #24407] perl crashes when usings 'exists $foo{}' with shared thread hash
[EMAIL PROTECTED] - Tue Nov 04 00:39:47 2003]:
Perl crashes on the following test program:
use threads;
use threads::shared;
my %hash : shared;
exists $hash{1};
The error message is: 'Free to wrong pool 15d26e8 not 1aeb8f0.'
From reading the discussion of this ticket it seems that this bug has
been fixed (for those testing it, its Windows-only). However there was
a lot of associated hand-wringing about mod_perl 2. Anyone know if that
went anywhere or needs more work?
[perl #7528] Bug with AUTOLOAD, XS, and : lvalue
[dmlloyd - Tue Aug 14 04:33:09 2001]:
If you extract the attached module and do this:
perl Makefile.PL
make
perl -Mblib -MBugDemo -e 'BugDemo-querble = 1234'
in perl 5.6.1, it works but in 5.7.2, you get:
Can't modify non-lvalue subroutine call at -e line 1.
-
Here's the gory details. I've declared (but NOT defined) a sub called
querble like this:
sub querble : lvalue method;
I've also got an xsub decared like this:
sub implemented_in_xs : lvalue method;
and impemented in BugDemo.xs. It simply makes a magic IV, just to
demonstrate the problem. Finally, I have an AUTOLOAD:
sub AUTOLOAD {
$_[0]-implemented_in_xs();
}
The end result should be that a call to 'querble' will be bounced into
'implemented_in_xs'. And this is exactly how it works in 5.6.1, but
not
in 5.7.2. I use this feature extensively in one of my modules, and it
would be a major bummer if it went away especially because I don't
see
how else I can make an lvalue xsub!
5.8.6 still has this bug. [EMAIL PROTECTED] has improved on it!
0 ~/Downloads/BugDemo-0.01$ bleadperl -Mblib -MBugDemo -e
'BugDemo-querble = 1234'
Bus error
[perl #27028] /$/ not honouring /m in some cases
[EMAIL PROTECTED] - Mon Feb 23 15:11:06 2004]: Test case #0: perl -e '$eol = qr/$/m; foo\nbar\n =~ /$eol/; print $-[0], \n' Test case #1: perl -e '$eol = qr/$/m; foo\nbar\n =~ /$eol(?:)/; print $-[0], \n' I'm getting the answer 7 from case #0 and 3 from case #1. The correct answer is 3. (The /$/m pattern should match at the embedded newline at position 3.) [EMAIL PROTECTED] reports 3 for both cases. Test case #2: perl -e '$eol = qr/$/; foo\nbar\n =~ /$eol/m; print $-[0], \n' #2 is the converse of #1; it outputs 3 where it should output 7. bleadperl reports 7. I believe this bug is fixed but I'd like to see a test added before closing it. The regex tests scare me.
[perl #2915] Inconsistent warnings with our
So, to sum up... I think we all agree these should all warn. my $x; our $x; # this currently does not our $x; my $x; my $x; my $x; our $x; our $x; and that this should not package Foo; our $x; package Bar; our $x; but this appears to be up in the air: package Foo; my $x; package Bar; our $x; Currently this warns. Rick's patch to fix my $x; our $x; changes this so that it does not warn on the grounds that the package Foo; our $x; package Bar; our $x case doens't warn either. But I say that's a special case to do with the fact that our's mix of two scoping mechanisms, lexical and package, runs afoul of multi-package-in-one-file programming idioms. package Foo; our @ISA = qw(...); # or $VERSION or @EXPORT or ... package Bar; our @ISA = qw(...); There's no corresponding idiom for package Foo; my $x; package Bar; our $x or vice-versa. Therefore, it should warn about the mask.
[perl #7840] Hash Behaviour differs v5.6.0 to v5.6.1
[EMAIL PROTECTED] - Tue Oct 23 22:13:02 2001]:
#! /usr/bin/perl -w
use strict;
use 5.6.0;
use constant HASH_KEY1 = 100;
use constant HASH_KEY2 = 200;
our %hash_desc = (
HASH_KEY1 = This is hash key one,
HASH_KEY2 = This is hash key two
);
foreach my $h_desc ( sort keys %hash_desc )
{
print $h_desc - $hash_desc{$h_desc}\n;
}
When executed under 5.6.0 the output is:
100 - This is the hash key one
200 - This is the hash key two
When executed under 5.6.1 the output is:
HASH_KEY1 - This is the hash key one
HASH_KEY2 - This is the hash key two
What gives? Why won't hashes in 5.6.1 use constants properly? (Please
don't tell me that Perl 5.6.0 is wrong ... I just might cry.)
5.6.0 was wrong, sorry. A lot of things about 5.6.0 were wrong.
$ perl5.4.5 -wle 'use constant FOO = 100; %h = ( FOO = 42 ); print
$h{FOO}'
42
$ perl5.5.4 -wle 'use constant FOO = 100; %h = ( FOO = 42 ); print
$h{FOO}'
42
$ perl5.6.2 -wle 'use constant FOO = 100; %h = ( FOO = 42 ); print
$h{FOO}'
42
$ perl5.8.6 -wle 'use constant FOO = 100; %h = ( FOO = 42 ); print
$h{FOO}'
42
= is documented as follows:
The = digraph is mostly just a synonym for the comma operator. It's
useful for documenting arguments that come in pairs. As of release
5.001, it also forces any word to the left of it to be interpreted as a
string.
*Any* word, including one that might also be a constant, is interpreted
as a string. %h = ( CONSTANT() = 42 ); is a work around.
[perl #7840] Hash Behaviour differs v5.6.0 to v5.6.1
[schwern - Thu Jul 14 16:47:07 2005]: = is documented as follows: The = digraph is mostly just a synonym for the comma operator. It's useful for documenting arguments that come in pairs. As of release 5.001, it also forces any word to the left of it to be interpreted as a string. *Any* word, including one that might also be a constant, is interpreted as a string. %h = ( CONSTANT() = 42 ); is a work around. Reopening this bug. On second thought, that's not really very obvious from the documentation. The trap should be documented. constant.pm documents it but perlop does not. Patch attached. While I was at it I also added some examples of useful uses of =. The = operator is a synonym for the comma, but forces any word (con- sisting entirely of word characters) to its left to be interpreted as a string (as of 5.001). This includes words that might otherwise be con- sidered a constant or function call. use constant FOO = something; my %h = ( FOO = 23 ); This is equivalent to: my %h = (FOO, 23); it is NOT: my %h = (something, 23); If the argument on the left is not a word, it is first interpreted as an expression, and then the string value of that is used. The = operator is helpful in documenting the correspondence between keys and values in hashes, and other paired elements in lists. %hash = ( key = $value ); login( $username = $password ); perlop.patch Description: Binary data
[perl #36538] perlfunc/our contradicts itself
[ysth - Wed Jul 13 14:13:53 2005]: Wording looks good, but I'd prefer to see Cuse strict 'vars'. Here it is again with that fixed plus the simple explaination lifted from Randal's column. http://www.stonehenge.com/merlyn/UnixReview/col54.html I also clarified in the cross-package example that the $bar used in package Bar refers to $Foo::bar. Didn't feel it was entirely obvious. Cour associates a simple name with a package variable in the current package for the remander of the lexical scope. The listed variables are declared to be valid globals within the enclosing block, file, or Ceval. That is, it has the same scoping rules as a my declaration, but does not create a local variable. When Cuse strict 'vars' is in effect, the Cour declaration lets you use the declared global variable without qualifying it with a package name. (But only within the lexical scope of the Cour declaration. In this it differs from use vars, which is package scoped.) If more than one value is listed, the list must be placed in parentheses. our $foo; our($bar, $baz); An Cour declaration declares a global variable that will be visible across its entire lexical scope, even across package boundaries. The package in which the variable is entered is determined at the point of the declaration, not at the point of use. This means the following behavior holds: package Foo; our $bar; # declares $Foo::bar for rest of lexical scope $bar = 20; package Bar; print $bar; # prints 20 as it refers to $Foo::bar our.patch Description: Binary data
[perl #6947] Perl5.6 debugger does not follow # source line references from cpp
[EMAIL PROTECTED] - Sat May 05 21:48:58 2001]:
. I run my perl scripts through cpp (for various reasons). I can't
use
the -P option because I use libraries and such which all need to be
run
through cpp.
. The output from cpp contains # lines of the form (for example):
# 1 /src/5.5longdistance/public_html/page.pc
# 1 /src/5.5longdistance/include/ld.h 1
# 1 /src/nbn/include/display.h 1
# 1 /src/nbn/include/class.h 1
BEGIN {push(@INC, '/src/nbn/widgets', '/src/nbn/comm',
'/virtuals/americom/lib')}
use Object;
# 3 /src/nbn/include/display.h 2
# 1 /src/5.5longdistance/include/ld.h 2
# 1 /src/5.5longdistance/public_html/page.pc 2
use Display;
unlink '/tmp/Errors';
#send errors to /tmp/Errors if not running in the debugger
$inDebugger = $INC{'/home/rwk/.perldb'};
if (!$inDebugger) {
open(STDERR, ' /tmp/Errors');
open(STDOUT, '| /usr/bin/tee --append /tmp/html') if -e
'/tmp/DumpHtml';
} else {
open(STDERR, STDOUT);
}
FORM::Execute();
END {
if (!$inDebugger ! -z '/tmp/Errors') {
#in case they occured before heading was printed
print Content-type: text/html\n\n;
print PRE\n;
my(@errors) = `cat /tmp/Errors`;
print @errors;
}
}
. When running the above in the perl debugger under perl5.004_04, it
correctly visits the source file and line specified by the # source
lines in the file. This make debugging easy, particularly within
emacs.
. Under perl5.6, it fails to do this and simply visits the file with
the
# source lines, rather than the file they refer to.
Can anyone tell me if there is a fix or work-arround for this problem?
You are correct in that Perl prior to 5.6 honored these comments and
that 5.6 and after do not.
$ cat ~/tmp/foo
#!/usr/bin/perl -w
# 1 /usr/include/ndbm.h
warn Foo;
0 ~/tmp$ perl5.4.5 ~/tmp/test
Foo at /usr/include/ndbm.h line 1.
0 ~/tmp$ perl5.5.4 ~/tmp/test
Foo at /usr/include/ndbm.h line 1.
0 ~/tmp$ perl5.6.2 ~/tmp/test
Foo at /Users/schwern/tmp/test line 4.
0 ~/tmp$ perl5.8.6 ~/tmp/test
Foo at /Users/schwern/tmp/test line 4.
However it was never documented that it would do so. It appears to have
been a quirk in the processing of #line directives, which are
documented at the end of perlsyn, that line was optional. I think it
was this change which clarified the behavior to avoid picking up
random comments as line directives.
http://public.activestate.com/cgi-bin/perlbrowse?patch=5108
-if (strnEQ(s, line , 5)) {
- s += 5;
- sawline = 1;
-}
+if (strnEQ(s, line, 4))
+ s += 4;
+else
+ return;
Before it would continue processing a comment as a possible #line
directive even if it did not see line. After it would stop if it did
not see line.
The work around is to use the documented #line 4 filename comments as
documented in perlsyn. Sorry if cpp does not output these.
[perl #21461] perl5.6.1 dos (djgpp) source build broke
Anybody tried djgpp in a while?
[perl #36206] t/op/pack leaking warnings in debugging bleadperl
[nicholas - Wed Jul 13 08:59:06 2005]: So I'm in the nominations for the Schwern award for the committer who leaves the most tickets open ? Not the most prestigious of titles to gain. The deciding factor for the judges was leaving this very ticket open. Masterful! ;P You'll be receiving your trophy: a car door with the *bing* *bing* your door is a jar circuits intact!
[perl #17487] ncftp only handles http
[EMAIL PROTECTED] - Tue Sep 07 06:28:44 2004]: I disagree with the final thought there. My machine did have a copy of wget on it so that wasn't the problem in my case (though it would be for a stock install of the current version of Mac OS X). Since it does present a problem for certain configurations, I would recommend requiring at least one FTP site be chosen. At very least, it could have given a warning. Requiring an FTP site is a coarse solution likely to just lead to a new set of complaints that CPAN.pm requires an FTP mirror. No, that's not the way. You mention that you have wget. CPAN.pm triest wget last after trying ncftp*. As its the most capable of all the options available it should be tried first. Then lynx. Then finally ncftp*. A patch for this is attached. CPAN.pm could check if the proto is HTTP and not try ncftp* but as they will be the last thing tried I think its more useful to try them than not. Who knows, maybe ncftpget will handle http urls in the future? CPAN.pm.patch Description: Binary data
[perl #24119] CPAN.pm error in Win32: uses rename() not File::Copy::move
The attached patch changes all the unsafe uses of rename() to File::Copy::move(). These are the ones which move a path to a different directory. All the rest work within the same dir and should be safe. CPAN.pm.patch Description: Binary data
[perl #24275] CPAN shell - online help not clear
[EMAIL PROTECTED] - Thu Oct 23 06:01:05 2003]: The online help of the CPAN shell has this entry: rNONE reinstall recommendations I checked with multiple coworkers and all of them (including me) misunderstood this as a command installing something. It should be made clear this command only checks version. You're right, that's not very clear. I went with updatable modules even though that loses the r mnemonic. reinstallable modules just didn't seem to properly describe listing the modules which have newer versions than you have installed. Also fixed a grammar nit in the i docs. CPAN.pm.patch Description: Binary data
[perl #24691] leading spaces on cpan configuration causes failure
[EMAIL PROTECTED] - Thu Dec 18 15:43:42 2003]: When I started cpan for the first time on perl-5.8.2 and started the configuration process I was cutting and pasting from a file. I grabbed the cpan directory location with leading spaces and pasted it. The results were this as the next prompt first line CPAN build and cache directory? [/login/warrend/.cpan] /proj/wdtold/warrend/cpan_perl-5.8.2_sun5.8 The path ' /proj/wdtold/warrend/cpan_perl-5.8.2_sun5.8' is not an absolute path. Please specify an absolute path The attached patch makes CPAN::FirstTime consistent in its stripping of leading and trailing spaces by building it directly into its prompt() function rather than hoping the caller deals with it. In two places I've left the input unstripped, the proxy username and password. Concievably one could have a username and password which begins or ends with spaces so its best to leave that unaltered. CPAN_FirstTime.patch Description: Binary data
[perl #28385] minor bug in cpan -- the i command does not find author
Forgot to CC p5p with my patch. Pumpkings and pumpkinglets, there's a patch for this bug. Please have a look at it in RT.
[perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns wrong value for Win 32
Ok, enough dithering. Let's kill this bug. File::Spec::Win32-canonpath() currently contains code to collapse .. so whether or not it should continue to do so in the future is outside the scope of this bug. That code is also busted and is the source of this bug. Attached is a patch to fix this bug. It replaces the collapsing code in canonpath() with a more reliable method. It also moves the code into its own method to simplify canonpath(). _collapse() goes into File::Spec::Unix because it is not platform specific. Tests have been added for this bug in both Win32 and Unix. fs.patch Description: Binary data
[perl #3149] 5.6 File::Glob documentation insufficient for use
Some documentation of the meta characters has been added to File::Glob but not much else. Just how much documentation of globbing do we want to put in the docs and how much can be go read X? Maybe a reference to a Unix tutorial on how globbing works?
[perl #36507] File::Copy::copy($foo, $foo) dies
The attached patch changes copy() so that it carps instead of croaking
when its asked to copy identical files. This is better because asking
to copy identical files is not an error (and the operation suceeds) its
just dubious.
I also added a check in move() to ensure it gets the right number of
arguments to match copy(). This revealed a mistake in the tests of
move() getting too many args.
Also the cross-partition fallback-to-copy code in move() is made safer
by guarding against a $SIG{__DIE__}.
FC.patch
Description: Binary data
[perl #1542] debugger space leak using conditional breakpoints
This bug appears to have been resolved somewhere before 5.8.6. The construct no longer consumes additional memory.
[perl #1726] Debugger: Break gets set on wrong subroutine
This problem still exists in 5.8.6 and [EMAIL PROTECTED]
[perl #2145] Debugger terminal handling
[EMAIL PROTECTED] - Sun Feb 13 23:29:43 2000]: When going out of range at the prompt in the debugger - i.e. pressing ctrl-n when there is no next line, or backspace when I'm at the start of the line, it crashes. I am unable to reproduce this but using 5.5.4 and Term::ReadLine::Gnu 1.08. Are you still experiencing the problem with newer perls and Term::ReadLine::Gnus?
[perl #3177] perl -d treats $array[0..3] differently than non-debugger
The debugger no longer sets $. $ perl -de 0 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 0 DB1 print $. DB2 The code works the same in the debugger as it does on the command line: $ perl -de 0 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 0 DB1 @a = qw(A B C); DB2 x $a[0..3], $a[1..3] 0 'B' 1 'A' DB3 $ perl -wle '@a = qw(A B C); print $a[0..3], $a[1..3]' Use of uninitialized value in range (or flip) at -e line 1. Use of uninitialized value in range (or flop) at -e line 1. Use of uninitialized value in range (or flip) at -e line 1. Argument isn't numeric in array element at -e line 1. BA
[perl #6749] Perl debugger outputs ctrl-\ wrongly
[EMAIL PROTECTED] - Thu Apr 05 19:58:47 2001]: The Perl debugger outputs strings containing the character ctrl-\ wrongly when using the x command. For example, x chr(28) results in \c\ and x \c\\ results in \c\\\. The results, however, are not valid Perl and will result in string terminator not found before end of line. The problem is in dumpvar.pl which x uses. The attached patch fixes this. dv.patch Description: Binary data
[perl #9472] Rebless, overloads and the debugger
This appears to have been fixed in the latest development version of perl.
[perl #8622] hash trouble in the perl debugger
Still an issue in 5.8.6 and [EMAIL PROTECTED]
[perl #8276] cannot interrupt accept call in debugger
This appears to have been fixed in the 5.8 track. With 5.8.6 I can ctrl-c at the accept() call and I am dumped into the debugger at the proper place. With 5.5.4 it didn't respond to ctrl-c at all, I wasn't dumped into the debugger nor did the process exit. So I'm reasonably sure this is resolved. Please let us know if it is not.
[perl #17765] UTF-8 in the debugger
[joemcmahon - Fri Jun 03 15:00:45 2005]:
Same program in the debugger:
% perl -de '
$_ = \x{100};
s/[\x{100}]/o/;
print $_\n;
'
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:2): $_ = \x{100};
DB1 c
Wide character in print at -e line 4.
?
This seems to fix the problem; it just adds :utf8 to the debugger's
output filehandle.
The problem is not the wide character in print warning. The problem
is that $_ is not 'o' as it is when run outside the debugger.
[perl #22758] debugger command |x swallows all output
[EMAIL PROTECTED] - Sun Jun 22 23:53:28 2003]: - The debugger command x works as expected, but |x shows no output at all: I am unable to reproduce this problem. What pager does the debugger think you're using? You can find out with this: $ perl -de 1 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 1 DB1 print DB::pager |/usr/bin/less
[perl #23651] Debugger dump failed for blessed REF object
Joe's patch appears to have gone in.
$ bleadperl -de 1
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:1): 1
DB1 x bless {}, Foo
0 Foo=HASH(0x810850)
empty hash
DB2 x bless \{}, Foo
0 Foo=REF(0x8a8ce0)
- HASH(0x8a8cf0)
empty hash
[perl #36206] t/op/pack leaking warnings in debugging bleadperl
[nicholas - Tue Jun 07 14:40:34 2005]: Thanks for the report. Rafael also spotted this about 8 hours ago. It's my fault (change 24714) and should be fixed by 24732. Was it?
[perl #36428] Problem with the debugger with conjunction to Encoding
[EMAIL PROTECTED] - Wed Jun 29 15:20:13 2005]: - the script starts here -- use Encode qw/encode decode/; my $var = +AQUBBQEF-/b+AXwBfAF8-; my $decoded = decode (UTF-7, $var); my $encoded = encode (UTF-7, $decoded); print $encoded; - the script ends here - when the script is run without the debugger (without perl -d), the output is - as expected - exactly the value of $var. However, trying to run the same program with -d makes Perl prematurely exit from the debugger or crash. Thorough debugging shows, that the problem occurs in line 36 of UTF7.pm (this file is part of the Perl distribution) Confirmed. On OSX 5.8.6 I get: main::(-:3):my $var = +AQUBBQEF-/b+AXwBfAF8-; DB1 c *** malloc_zone_malloc[1462]: argument too large: 4281226766 Out of memory! And with [EMAIL PROTECTED] it simply hangs but does not consume additional memory.
[perl #1376] Memory leak in IO::Socket ?
[RT_System - Sun Sep 19 18:30:17 1999]:
I appear to be running into a memory leak in IO::Socket which I can't
fix. The
following example:
#!/usr/bin/perl -w
use strict;
use IO::Socket;
my $RemoteHost = 'localhost';
while (1) {
my $Socket = new IO::Socket::INET(PeerAddr = $RemoteHost,
PeerPort = 80,
Proto = 'tcp',
Type = SOCK_STREAM,
);
$Socket-close();
undef $Socket;
}
I can't see anything obviously wrong with this.
I cannot replicate this on OS X using 5.4.5 and 5.5.4. Are you still
having this problem in newer Perls and versions of IO?
[perl #1442] Missing Label and -w
[RT_System - Sun Sep 19 20:00:34 1999]:
This is with _61 ( perl -wc doesn't report any errors )
use strict;
for my $i (1..5) {
if ( $i == 2 ) { next Loop; }
}
I presume you're reporting that perl -cw does not report the lack of a
loop label as an error? This is correct because a loop label could be
created at run time. Its odd but can happen.
$label = Loop;
eval qq[$label: for(1..5) {
foo();
print Never run
}];
sub foo { for (1..5) { next Loop } }
One of the facts of life living with such a dynamic language.
[perl #1500] Re: The extent of double-quotish interpolation
[RT_System - Mon Sep 20 02:46:44 1999]: Ah, I think I see what you mean now. You want these to behave differently: DB1 print $count = @array = ((undef) x 3)[0,1,2] 0 DB2 print $count = @array = ()[0,1,2] 0 You'd have the first version start returning three, but leave the second version alone. The potential for breakage here is certainly reduced compared to what I misunderstood the original request to be, since there are fewer cases that would change. And it's quite possible that it's the latter case that people rely upon more than it is the former one. Whether it's exclusively the latter case that matters, I wonder. But you can't know what color the yolk is until you break the egg. Omlette makers can sometimes tell without breaking anything. :-) And they do behave differently. 0 ~/tmp$ perl -le 'print $count = @array = ((undef) x 3)[0,1,2]' 3 0 ~/tmp$ perl -le 'print $count = @array = ()[0,1,2]' 0 So I guess whatever this was about its been resolved.
[perl #1503] Re: [PATCH perl5.004_67] Add Errno in ext/
[RT_System - Mon Sep 20 05:51:22 1999]:
For some obscure reasons I did test the %! auto-require stuff yesterday
and found that it doesn't work (in Perl 5.005_03 and 5.005_61). Well
actually it does work at runtime, just not at compile-time, exactly as the
comments indicate. But isn't this quite confusing:
print $_\n foreach keys %{'!'};
works (loads Errno.pm), but
print $_\n foreach keys(%!);
doesn't.
This appears to be resolved in 5.8.6 and probably earlier.
[perl #1662] Perl on HP-UX
[EMAIL PROTECTED] - Tue Oct 19 00:35:42 1999]: Alvin White BellSouth Telecommunications Lacking any information there's nothing to be done but close this bug.
[perl #1693] CPAN::shell to work in XEmacs M-x shell
perl -MCPAN -e shell works for me with GNU emacs 21.2.1 and XEmacs 21.4 (patch 15) on OS X using perl 5.8.6.
[perl #1784] 2 problems with File::Spec::Win32
[EMAIL PROTECTED] - Mon Nov 15 05:50:21 1999]: 1. rel2abs goes into an infinite loop if the $base parameter is omitted. Confirmed a bug in 5.5.4. Confirmed fixed in 5.8.6 if not earlier. 2. canonpath does not support the optional $reduce_ricochet parameter. $reduce_ricochet has been removed from File::Spec.
[perl #1807] chomp() can be confusing
[EMAIL PROTECTED] - Thu Nov 18 23:18:09 1999]:
Is there any possibility of having chomp() be modified to recognize
\n, \r,
and \r\n as line-endings to chomp?
Do you mean that chomp(), rather than being equivalent to:
s{$/\z}{};
should be:
s{(\r|\n|\r\n)\z}{};
?
[perl #1844] FindBin fails if all directories in cwd are not readable
[EMAIL PROTECTED] - Wed Dec 01 06:23:20 1999]: Possible solutions: Fix Cwd::abs_path(), so it doesn't do that. Possibly, rather than warning and returning, it should use fast_abs_path() instead, which should handle warnings if they need to be given. Alternatively, have FindBin use a fallback if abs_path() fails. I am unable to replicate this behavior on OS X using 5.4.5 or 5.5.4. As the implementation of Cwd::abs_path() changes on different operating systems I cannot be sure this bug does not still exist. Can you tell us what operating system you were using, and version of Perl? Can you also try this out on a newer version of Perl?
[perl #1987] ISA not supported
[EMAIL PROTECTED] - Thu Jan 13 10:55:24 2000]: I check it on http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-09/msg1.html but didn't help me much, is it a bug ? And is there any work around for this? There has been a lot of improvements done on h2ph in recent years, its probable this bug has been resolved but I cannot check without a copy of isa_defs.h. Can you provide it?
[perl #1997] DynaLoader doesn't dlclose XS code on interpreter exit
[EMAIL PROTECTED] - Tue Jan 18 07:49:50 2000]: DynaLoader assumes that exiting of the perl interpreter is the same thing as exit of the entire application. In the case where perl is built as a .so and embedded inside something else (e.g. Apache/mod_perl) it is certainly not the same thing. The failure of DynaLoader to dlclose the XS modules leads to a very insiduous bug. The XS modules are left loaded in memory, and if the perl libperl.so is subsequently reloaded via dlopen, it is often loaded into a different address. The orphaned XS .so files are still in memory, linked to a 'ghost' of the perl libperl.so. This causes all sorts of insiduous memory and heap corruption problems. DynaLoader maintains a list of opened .so files in dl_librefs - on exit it should dlunload all the objects in this list. Looking at DynaLoader and skimming the discussion of this bug it seems like it has been applied and fixed. Could someone more familiar with DynaLoader please confirm?
[perl #2032] Problem in documentation of Fcntl constants
[EMAIL PROTECTED] - Tue Jan 25 02:26:08 2000]: After a discussion in the perl.misc newsgroup, everyone agreed that the operation should be a logical OR, not an ADD. I'm submitting this as a documentation bug, in hopes that this is the appropriate channel to get the document changed. In conjunction with the bug in the definition of the constants themselves (reported in my previous Email), this caused me tremendous problems. Anyone remember what this bug was all about? I read what information is in the tracker but it rapidly devolves into an autoload discussion.
[perl #1760] regexp causes SIGSEGV (stack overflow?)
Still a problem in [EMAIL PROTECTED]
[perl #2106] multi-threaded perl segfaults
5.005 threads are due to be eliminated in 5.10. Closing this bug.
[perl #2269] unpack(NaN) big baddaboom
[EMAIL PROTECTED] - Mon Mar 06 02:33:55 2000]: Running following program causes Floating point exception on FreeBSD 3.2-STABLE *and* 4.0-CURRENT #0: Tue Feb 29 02:11:52 AST 2000 (but not on Linux 2.3.44 #12 SMP) (all 5.00503) ===8==8==8==8 #!/usr/bin/perl my $packed = \0\0\xc0\x7f; print STDERR len: , length($packed), bytes: , unpack(H*, $packed), \n; my $float = unpack(f, $packed); print STDERR float done\n; print STDERR float: $float\n; exit 0; ===8==8==8==8 hayek$ ./moo.pl len: 4 bytes: c07f float done Floating point exception hayek$ echo $? 136 hayek$ ===8==8==8==8 Anyone have a FreeBSD machine handy with a recent Perl on it to try this out?
[perl #2915] my $x; our $x; does not give masked warning
[EMAIL PROTECTED] - Thu Mar 30 21:52:59 2000]: Shouldn't perl5.6.0 -we 'my $x; our $x; $x=0' generate some sort of redeclared warning?The other cases (two mys or two ours or our before my) all do. This is still an issue in 5.9.x. I'd agree, there should be a warning particularly because all other combinations issue a warning: $ bleadperl -lwe 'my $x = 42; our $x = 23; print $x' 23 $ bleadperl -lwe 'my $x = 42; my $x = 23; print $x' my variable $x masks earlier declaration in same scope at -e line 1. 23 $ bleadperl -lwe 'our $x = 42; my $x = 23; print $x' my variable $x masks earlier declaration in same scope at -e line 1. 23 $ bleadperl -lwe 'our $x = 42; our $x = 23; print $x' our variable $x masks earlier declaration in same scope at -e line 1. 23 And is it appropriate that perl5.6.0 -we 'our $x' generates a used only once, but the corresponding my does not? This appears to have been resolved.
[perl #3269] no warnings foo without use warnings turns off all warnings.
[EMAIL PROTECTED] - Fri May 19 04:23:23 2000]: $ perl -wle 'foo.bar' Unquoted string foo may clash with future reserved word at -e line 1. Unquoted string bar may clash with future reserved word at -e line 1. Useless use of concatenation (.) in void context at -e line 1. $ perl -wle 'no warnings bareword; foo.bar' $ It seems that 'no warnings foo' without a preceding use warnings turns off all warnings even if -w is given! The latter should warn about the void use of concatenation. $ perl -wle 'use warnings all; no warnings bareword; foo.bar' Unquoted string foo may clash with future reserved word at -e line 1. Unquoted string bar may clash with future reserved word at -e line 1. Useless use of concatenation (.) in void context at -e line 1. $ And this should have warned only about the void use of concatenation. No, Unquoted string... is a reserved warning.
[perl #24119] CPAN.pm error in Win32: uses rename() not File::Copy::move
[EMAIL PROTECTED] - Sun Oct 05 08:06:14 2003]: CPAN.pm (invoked as cpan in the command shell) reports a permission problem trying to move a directory. The trouble is that CPAN.pm is using the rename() function, which in Win32 can change a file's name but not move it from one directory to another. A convenient solution is for CPAN.pm to use File::Copy::move() instead. CPAN.pm already has a use statement for File::Copy anyway. In all the discussion about the behavior of rename() on Win32 the original point of this bug was lost. CPAN.pm is still riddled with rename() calls.
[perl #36502] File::Copy::mv fails to replicate behavior of Unix mv
Attached is a test patch to test File::Copy while copying/moving across partitions. It simulates this by overriding rename() so that it always fails. All tests are done twice, once with a working rename, once without. It also adds a test for this bug, it checks to make sure the destination of a move() retains the source's mtime. The test is written in such a way that it should continue to work on systems which do not support mtime or utime(). mtime.patch Description: Binary data
[perl #5634] CPAN.pm v1.59 chdirs before looking for perl
[schwern - Tue Jul 15 18:31:18 2003]: The attached patch fixes this bug by the simple method of storing the Perl we started with as an absolute path before anything is done. Then perl() can reference this information. I can't see how this could go wrong on MacOS. I've also taken the liberty of speeding up perl() by caching its result. This patch was never applied. I've attached a better patch which simply moves the find perl logic from individual CPAN::Distribution objects to be a function of the CPAN. The location of Perl is simply cached in a global. CPAN.pm.patch Description: Binary data
[perl #7327] Typos in Configure
[EMAIL PROTECTED] - Mon Jul 23 11:29:41 2001]: Thanks for the perl CPAN module! I have a few typos and comments. This is actually the output of the Configure script and has nothing to do with CPAN.pm. CPAN.pm: Going to build G/GS/GSAR/perl-5.6.1.tar.gz In some special cases, particularly when building perl5 for distribution, it is convenient to distinguish between the directory in which files should be installed from the directory (/usr/local) in which they will eventually reside. For most users, these two directories are the same. 'installed from the directory' should be 'installed and the directory'. The wording has been fixed to read: In some special cases, particularly when building $package for distribution, it is convenient to distinguish the directory in which files should be installed from the directory ($prefix) in which they will eventually reside. Many scripts expect perl to be installed as /usr/bin/perl. I can install the perl you are about to compile also as /usr/bin/perl (in addition to /usr/local/bin/perl). Do you want to install perl as /usr/bin/perl? [y] If there's already a /usr/bin/perl, don't default to replacing it. This has been fixed and now defaults to no. Many scripts expect perl to be installed as /usr/bin/perl. If you want to, I can install the perl you are about to compile as /usr/bin/perl (in addition to /usr/local/bin/perl). However, please note that because you already have a /usr/bin/perl, overwriting that with a new Perl would very probably cause problems. Therefore I'm assuming you don't want to do that (unless you insist). Do you want to install perl as /usr/bin/perl? [n] Also, if the user doesn't actually have write permissions to the destination directory, there should probably be a warning, so they can rerun the installation as root, change permissions on that dir, install to a temporary directory, or at least understand what's going on. This is not wise as it is often desirable to build perl (and anything else) as a normal user and install it as root to ensure that if something goes wild during the build process it at least can't rampage over the system as root. The perl executable is normally obtained by linking perlmain.c with libperl.a, any static extensions (usually just DynaLoader), and any other libraries needed on this system (such as -lm, etc.). Since your system supports dynamic loading, it is probably possible to build a shared libperl.so. If you will have more than one executable linked to libperl.so, this will significantly reduce the size of each executable, but it may have a noticeable affect on performance. The default is probably sensible for your system. 'noticeable affect on performance.' should be 'noticeable effect on performance.' This hasn't been fixed. Could one of the metaconfig gurus patch that typo up?
[perl #35847] File::Find not performing as documented
[EMAIL PROTECTED] - Tue May 17 03:40:07 2005]:
Not in all cases. lstat() does not always occur in directories
that don't have any subdirectories.
linux% cd ~/bin # Do not run test with . = dir-with-too-many-files
linux% cat ../temp.pl
use File::Find;
$File::Find::dont_use_nlink = $ARGV[0];
my @files;
find sub { push @files, $File::Find::name if -f _ /\.pm$/ }, @INC;
print join \n, @files,'';
linux% perl ../temp.pl 0 | wc -l
434
linux% perl ../temp.pl 1 | wc -l
943
linux% perl -v
This is perl, v5.8.3 built for i586-linux
I am unable to replicate this problem with either 5.8.1, 5.8.6 or
[EMAIL PROTECTED] I don't have a 5.8.3 handy to try.
[perl #22051] segfault (deep recursion?) in regex match
Here is the program that segfaults with both perl-5.8.0 from debian as
well as with my own perl-5.8.1 MAINT19040:
# just get the test data into $data
use LWP::Simple;
$data = get http://data.plan9.de/macbeth.xml;;
# the segfault occurs on the second round (i think) in the first
regex.
for(;;) {
$data =~ /\G([:?])((?:[^]+|[^:?])*)/xgcs or last;
$data =~ /\G([:?])((?:[^:?]+|[:?][^])*)/gcs or last;
}
when I run this program I get a segfault because of a very deep
recursion:
#0 S_regmatch (prog=0x81252a8) at regexec.c:2237
#1 0x080e605e in S_regmatch (prog=0x8125318) at regexec.c:3244
#2 0x080e5068 in S_regmatch (prog=0x81252a8) at regexec.c:3789
#3 0x080e605e in S_regmatch (prog=0x81252a8) at regexec.c:3244
#4 0x080e605e in S_regmatch (prog=0x8125318) at regexec.c:3244
#5 0x080e5068 in S_regmatch (prog=0x81252a8) at regexec.c:3789
#6 0x080e605e in S_regmatch (prog=0x81252a8) at regexec.c:3244
...
#18941 0x080e5068 in S_regmatch (prog=0x81252a8) at regexec.c:3789
#18942 0x080e605e in S_regmatch (prog=0x8125318) at regexec.c:3244
#18943 0x080e5cef in S_regmatch (prog=0x8125250) at regexec.c:3079
#18944 0x080e2c4f in S_regtry (prog=0x812520c, startpos=0x8431819
?\n!DOCTYPE PLAY SYSTEM \play.dtd\\n\nPLAY\nTITLEThe Tragedy
of Macbeth/TITLE\n\nFM\nPText placed in th
Confirmed still a bug in 5.8.1, 5.8.6 and [EMAIL PROTECTED]
[perl #24170] ReadParse in the CGI docs
[EMAIL PROTECTED] - Thu Oct 09 08:06:20 2003]:
use CGI;
CGI::ReadParse
print The value of the antique is $in{antique}.\n;
Adding the missing ;, it will still not work since it's parsed as the
literal string CGI::ReadParse. The right way is of course:
use CGI;
CGI::ReadParse();
print The value of the antique is $in{antique}.\n;
He's right. This fix should be applied.
[perl #22236] File::Basename behavior is misleading
[EMAIL PROTECTED] - Sun Jul 13 12:04:02 2003]: This makes dirname($f)./.basename($f) point to the same file as $f when $f ends in / (or your platform's directory separator char). The behavior's now consistent with the shell, i.e. $f = /usr/lib//; basename($f); # = lib dirname($f); # = /usr My only issue with this patch is it contradicts the existing docs... The basename() routine returns the first element of the list pro- duced by calling fileparse() with the same arguments, except that it always quotes metacharacters in the given suffixes. Except the existing docs contradict itself. It is provided for programmer compatibility with the Unix shell command basename(1). So EITHER it works the same as fileparse() OR it works the same as basename(1). Given the recent discussion about dirname()'s behavior (see 36435) concluded that its more important to be compatible with the shell, I think this change should go in. Attached is a patch to make basename() strip trailing path seperators before processing as well as docs to that effect and more tests. I've also documented the dirname($path) . '/' . basename($path) assertation. It also consolidates all the trailing path seperator stripping into one function so we don't have repeat the code in dirname() and basename(). fb.patch Description: Binary data
