Smoke [5.9.0] 25339 FAIL(m) openbsd 3.6 (i386/1 cpu)

2005-08-31 Thread Steven P. Schubiger
Automated smoke report for 5.9.0 patch 25339
accognoscere.homeunix.org: AMD Athlon(TM) XP 1800+ (AuthenticAMD 686-class) 
(i386/1 cpu)
onopenbsd - 3.6
using cc version 2.95.3 20010125 (prerelease, propolice)
smoketime 3 minutes 1 seconds (average 22.625 seconds)

Summary: FAIL(m)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   25339 Configuration (common) none
--- -
m - m - 
m - m - -Duse64bitint
m - m - -Duseithreads
m - m - -Duseithreads -Duse64bitint
| | | +- PERLIO = perlio -DDEBUGGING
| | +--- PERLIO = stdio  -DDEBUGGING
| +- PERLIO = perlio
+--- PERLIO = stdio


-- 
Report by Test::Smoke v1.19#716 running on perl 5.8.5
(Reporter v0.016 / Smoker v0.015)



RE: [perl #37029] Perl bug - help

2005-08-31 Thread Yeoman, Dave
Peter,  

What we have noticed is; perl v5.8.0 $FindBin::Bin is returning
/usr/local/bin and perl v5.8.5 $FindBin::Bin is returning
/usr/local/bin/

The next / at the end of bin.

Dave Yeoman
System Engineer - Enterprise Performance
Galileo International
Phone:  (303) 397-5721
E-mail: [EMAIL PROTECTED] 


-Original Message-
From: Steve Peters via RT [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 30, 2005 1:50 PM
To: Yeoman, Dave
Subject: Re: [perl #37029] Perl bug - help

On Tue, Aug 30, 2005 at 06:51:22AM -0700, Yeoman, Dave wrote:
 # New Ticket Created by  Yeoman, Dave 
 # Please include the string:  [perl #37029]
 # in the subject line of all future correspondence about this issue. 
 # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37029 
 
 
 I'm by no means an expert with perl, but I need some Perl help.  We have
one
 x440 server with RH 3.0.5 and perl v5.8.0 built for
 i386-linux-thread-multiand and another server x445 upgraded with RH 4.0
perl
 v5.8.5 built for i386-linux-thread-multi.  The server with Perl v5.8.5
 produces different results from the pop (line 458 below) and I'm not sure
 why.  Can you help answer my question?
 
  

If Cpop() is returning different results, then the array it is pop'ping
off
of is likely getting populated in a different order, or with different
results.
From what you've included, though, its hard to say.  How are the results
different in 5.8.5 from 5.8.0?

Steve Peters
[EMAIL PROTECTED]

The information in this electronic mail message is sender's business
Confidential and may be legally privileged. It is intended solely for the
addressee(s). Access to this Internet electronic mail message by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it is prohibited and may be unlawful.  
The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. Cendant is not liable for any loss or damage arising in any
way from this message or its attachments.


Re: [EMAIL PROTECTED] ext/Dev/Peek/t/peek.t fix for VMS

2005-08-31 Thread Rafael Garcia-Suarez
John E. Malmberg wrote:
 This fixes test 21 on blead-perl to pass on VMS.  The hash set by VMS 
 now has the READONLY and FAKE attributes, and two of the three VMS 
 resources that are represented by ENV hashes are not null terminated and 
 can contain binary values.

Thanks, applied as change #25340.


Re: [perl #36967] Pod/Perldoc.pm bug with -m switch

2005-08-31 Thread Enrico Sorcinelli
On Mon, 22 Aug 2005 10:41:15 -0600
Jim Cromie [EMAIL PROTECTED] wrote:

Hi Jim,

 From the point of view of Pod/Perldoc.pm there's no differences between 
 .pod or
 .pm files or, more in general, between a generic file or Perl module.
 For example, I can view the source of 'media.types' file shipped with LPW:
 
  % perldoc -m LWP::media.types
 
 The bug (or 'strange' behaviour if you prefere) I've noted is that
 Pod/Perldoc.pm adds .pod extension to perldoc argument only under certain 
 (and,
 in this case, inconsistent) circumstances and still I don't understand why.
 
   
 
 I think the biggest reason is if you have both Foo.pm and Foo.pod
 your previous patch (I think) will prefer Foo.pod, making Foo.pm 
 unavailable.

I agree with this, but one can check also for Foo.pod after checking Foo.pm, not
disabling that at all.
Currently, if Foo.pm isn't found, there is no chanche to check also Foo.pod
again (in the same path).

Attached patch maintains precedence of .pm over .pod (in order to looking at the
code first with -m switch) but also check for .pod suffix then.

 this may also be reason for looking in pods/*

In general, putting pure pod under pod/pods dedicated directory is a good thing
(and IMHO it should be the rule) but is poorly documented and/or suggested.

Regards

- Enrico



Perldoc.pm-3.14-switchm2_patch
Description: Binary data


[perl #37036] perl segfault at 'compile'-time

2005-08-31 Thread via RT
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #37036]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37036 



This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.7.


-
Hi, i've found a small code that triggers a segfault on the
following perl versions :

5.8.4 (ubuntu package)
5.8.7 (debian testing package)
5.8.7 (freebsd port 5.3-RELEASE)
5.9.1 (compiled on my linux debian testing i386, gcc-4.0.1)

unaffected versions :
version 5.005_03 built for sun4-solaris

Priority is low, since this code is incorrect, but it might help
resolving other issues.

the segfault does not appear when not using 'strict'.
note that no code is executed since it's in a sub that is never
called at runtime.

-- CODE BEGINS HERE --
#!/usr/bin/perl
use strict;
sub s { open $X, my $Y, r; }
-- CODE ENDS HERE --

hope it might help,

Nicolas

-
---
Flags:
category=core
severity=low
---
Site configuration information for perl v5.8.7:

Configured by Debian Project at Thu Jun  9 00:28:22 EST 2005.

Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
  Platform:
osname=linux, osvers=2.4.27-ti1211, archname=i386-linux-thread-multi
uname='linux kosh 2.4.27-ti1211 #1 sun sep 19 18:17:45 est 2004 i686 
gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN 
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr 
-Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr 
-Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 
-Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.7 
-Dsitearch=/usr/local/lib/perl/5.8.7 -Dman1dir=/usr/share/man/man1 
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl 
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib 
-Dlibperl=libperl.so.5.8.7 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define 
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN 
-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.3.6 (Debian 1:3.3.6-6)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.7
gnulibc_version='2.3.2'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:


---
@INC for perl v5.8.7:
/etc/perl
/usr/local/lib/perl/5.8.7
/usr/local/share/perl/5.8.7
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.

---
Environment for perl v5.8.7:
HOME=/home/tassadar
[EMAIL PROTECTED]
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/home/tassadar/bison:/home/tassadar/bin/:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
PERL_BADLANG (unset)
SHELL=/bin/zsh



Re: Optree Generation

2005-08-31 Thread mohammad yaseen
Hi Yitzchak Scott,
 

when you run the command given below 

perl -I../lib -MO=Concise,BEGIN,CHECK,INIT,END,-exec -e '$a=$b  print 
q/foo/'

 

i am getting following output in EBCDIC platform. 

 

BEGIN 1:

1  ; nextstate(B::Concise -249 Concise.pm:306) v/2

2  $ const(PV strict.pm) s/BARE

3  1 require sK/1

4  ; nextstate(B::Concise -249 Concise.pm:306) v/2

5  ; nextstate(B::Concise -249 Concise.pm:306) /2

6  0 pushmark s

7  $ const(PV strict) sM

8  $ const(PV refs) sM

9  $ method_named(PVIV -1585856300)

a  1 entersub[t1] KS*/TARG,2

b  1 leavesub[1 ref] K/REFC,1

BEGIN 2:

c  ; nextstate(B::Concise -234 Concise.pm:329) v/2

d  $ const(PV warnings.pm) s/BARE

e  1 require sK/1

f  ; nextstate(B::Concise -234 Concise.pm:329) v/2

g  ; nextstate(B::Concise -234 Concise.pm:329) /2

h  0 pushmark s

i  $ const(PV warnings) sM

j  $ const(PV qw) sM

k  $ method_named(PVIV -1585856300)

l  1 entersub[t1] KS*/TARG,2

m  1 leavesub[1 ref] K/REFC,1

-e syntax OK

 

As far as my understanding goes i thought -1585856300 is the address of the 
function. if that is the case then -1585856300 is not correct. what exactly 
-1585856300 represent. 

 

When i was debugging this i reached lib/B.pm there i tried to print  $self-IV 
thinking that it is getting number from this variable and it happed to be 
right. Futher i could not proceed as i did not have clear understand here 
itself.

Thanks and regards

Yaseen


Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote:
Can you tell us what your goal is?


-
 Start your day with Yahoo! - make it your home page 

Smoke [5.9.3] 25339 FAIL(F) bsd/os 4.1 (i386/1 cpu)

2005-08-31 Thread kane
Automated smoke report for 5.9.3 patch 25339
fixit.xs4all.nl: Pentium II (i386/1 cpu)
onbsd/os - 4.1
using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
smoketime 3 hours 55 minutes (average 1 hour 57 minutes)

Summary: FAIL(F)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   25339 Configuration (common) none
--- -
F F - - -Duse64bitint
O O - - 
| | | +- PERLIO = perlio -DDEBUGGING
| | +--- PERLIO = stdio  -DDEBUGGING
| +- PERLIO = perlio
+--- PERLIO = stdio


Failures: (common-args) none
[stdio] -Duse64bitint
../t/op/int.t...FAILED 11

[perlio] -Duse64bitint
../t/op/int.t...FAILED 11
Inconsistent test results (between TEST and harness):
../lib/Net/hostent.tFAILED at test 4

-- 
Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503
(Reporter v0.019 / Smoker v0.023)



Re: Optree Generation

2005-08-31 Thread Yitzchak Scott-Thoennes
On Tue, Aug 30, 2005 at 11:46:46PM -0700, mohammad yaseen wrote:
 when you run the command given below 
 
 perl -I../lib -MO=Concise,BEGIN,CHECK,INIT,END,-exec -e '$a=$b  print 
 q/foo/'

Also with just: perl -I../lib -MO=Concise,BEGIN,-exec -e0

As instructed, Concise is dumping out the BEGIN blocks, even some of
the ones in Concise.pm itself, specifically the two lines:

no strict 'refs';
  and 
no warnings 'qw'; # Possible attempt to put comments...; use #7

The method_named ops are the unimport() method calls that no generates.
It seems that the SV that holds the method name has an integer value also
(perhaps related to sharing?) and Concise is showing that in preference
to the string value.

The following (untested) would be an unobtrusive way to fix this in
this one case, though it might be better for concise_sv to dump both
the string and numeric values when both are present.

--- perl/ext/B/B/Concise.pm.orig2005-08-25 02:43:55.0 -0700
+++ perl/ext/B/B/Concise.pm 2005-08-31 05:17:14.543707200 -0700
@@ -627,7 +627,7 @@
 }
 
 sub concise_sv {
-my($sv, $hr) = @_;
+my($sv, $hr, $preferpv) = @_;
 $hr-{svclass} = class($sv);
 $hr-{svclass} = UV
   if $hr-{svclass} eq IV and $sv-FLAGS  SVf_IVisUV;
@@ -650,6 +650,8 @@
}
if (class($sv) eq SPECIAL) {
$hr-{svval} .= [Null, sv_undef, sv_yes, sv_no]-[$$sv];
+   } elsif ($preferpv  $sv-FLAGS  SVf_POK) {
+   $hr-{svval} .= cstring($sv-PV);
} elsif ($sv-FLAGS  SVf_NOK) {
$hr-{svval} .= $sv-NV;
} elsif ($sv-FLAGS  SVf_IOK) {
@@ -764,12 +766,13 @@
 elsif ($h{class} eq SVOP or $h{class} eq PADOP) {
unless ($h{name} eq 'aelemfast' and $op-flags  OPf_SPECIAL) {
my $idx = ($h{class} eq SVOP) ? $op-targ : $op-padix;
+   my $preferpv = $h{name} eq method_named;
if ($h{class} eq PADOP or !${$op-sv}) {
my $sv = (($curcv-PADLIST-ARRAY)[1]-ARRAY)[$idx];
-   $h{arg} = [ . concise_sv($sv, \%h) . ];
+   $h{arg} = [ . concise_sv($sv, \%h, $preferpv) . ];
$h{targarglife} = $h{targarg} = ;
} else {
-   $h{arg} = ( . concise_sv($op-sv, \%h) . );
+   $h{arg} = ( . concise_sv($op-sv, \%h, $preferpv) . );
}
}
 }

End of Patch.


 i am getting following output in EBCDIC platform. 
 
  
 
 BEGIN 1:
 
 1  ; nextstate(B::Concise -249 Concise.pm:306) v/2
 
 2  $ const(PV strict.pm) s/BARE
 
 3  1 require sK/1
 
 4  ; nextstate(B::Concise -249 Concise.pm:306) v/2
 
 5  ; nextstate(B::Concise -249 Concise.pm:306) /2
 
 6  0 pushmark s
 
 7  $ const(PV strict) sM
 
 8  $ const(PV refs) sM
 
 9  $ method_named(PVIV -1585856300)
 
 a  1 entersub[t1] KS*/TARG,2
 
 b  1 leavesub[1 ref] K/REFC,1
 
 BEGIN 2:
 
 c  ; nextstate(B::Concise -234 Concise.pm:329) v/2
 
 d  $ const(PV warnings.pm) s/BARE
 
 e  1 require sK/1
 
 f  ; nextstate(B::Concise -234 Concise.pm:329) v/2
 
 g  ; nextstate(B::Concise -234 Concise.pm:329) /2
 
 h  0 pushmark s
 
 i  $ const(PV warnings) sM
 
 j  $ const(PV qw) sM
 
 k  $ method_named(PVIV -1585856300)
 
 l  1 entersub[t1] KS*/TARG,2
 
 m  1 leavesub[1 ref] K/REFC,1
 
 -e syntax OK
 
  
 
 As far as my understanding goes i thought -1585856300 is the address of the 
 function. if that is the case then -1585856300 is not correct. what exactly 
 -1585856300 represent.

No, it's not an address; I'm not sure what it is, though. 


Re: [perl #37029] Perl bug - help

2005-08-31 Thread Steve Peters
On Tue, Aug 30, 2005 at 02:29:36PM -0600, Yeoman, Dave wrote:
 Peter,  
 
 What we have noticed is; perl v5.8.0 $FindBin::Bin is returning
 /usr/local/bin and perl v5.8.5 $FindBin::Bin is returning
 /usr/local/bin/
 
 The next / at the end of bin.
 

OK, this is problem has been previously resolved.  The problem is caused
by a patch to the Fedora/RedHat Perl package.  See previously resolved ticket
#30507.  A patch to solve the problem has been accepted for future Perls,
but has not been released yet.  The patch is available at:

http://public.activestate.com/cgi-bin/perlbrowse?patch=24753

An updated Perl with this patch may also be available from RedHat/Fedora.

Steve Peters
[EMAIL PROTECTED]


[perl #37038] Global regular matches generate invalid pointers

2005-08-31 Thread via RT
# New Ticket Created by  Thilo Girmann 
# Please include the string:  [perl #37038]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37038 



This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.7.


-
[Please enter your report here]

(I'm sending this message again using a mail client as it appears
to me that it wasn't delivered by sendmail)

When:
* doing a global regular match
* using $1 $2 etc. to retrieve extracted substrings
* the original string does not exist any longer

then $1 $2 etc. is pointing to an unallocated piece of memory.
This way it's possible to return Perl's internal data structures
if the piece of memory got re-used and possibly also cause Perl
to crash if that piece of memory has been returned to the
operating system.

Here's a simple example to confirm the bug (tested under Windows
NT / ActivePerl 5.8.7 and Linux 2.4 / Perl 5.8.0):

use strict;
use warnings;
my $s = abcd;
$s =~ /(..)(..)/g;
$s = $1;
$s = $2;
print $s\n;


The statement $s = $1 causes Perl to re-use the string abcd
for storing the first half (ab) and add a terminating zero.
$2 still points to the original second half but the character
c got overwritten neanwhile.

So if the bug is present you will get  c or just c printed
out instead of the expected cd.



[Please do not change anything below this line]
-
---
Flags:
category=core
severity=low
---
Site configuration information for perl v5.8.7:

Configured by builder at Mon Jun  6 13:36:05 2005.

Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
  Platform:
osname=MSWin32, osvers=5.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=define use5005threads=undef useithreads=define usemultiplicity=de
fine
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE 
-DNO_STRICT -DHAVE_DES_FCRYPT -DBUILT_BY_ACTIVESTATE -DNO_HASH_SEED 
-DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO 
-DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='12.00.8804', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', 
lseeksize=8
alignbytes=8, prototype=define
  Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf  
-libpath:C:\Perl\lib\CORE  -machine:x86'
libpth=\lib
libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib 
uuid.lib ws2_32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib 
msvcrt.lib
perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib 
uuid.lib ws2_32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib 
msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
  Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf  
-libpath:C:\Perl\lib\CORE  -machine:x86'

Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
#  if !defined(PERL_DARWIN)
Iin_load_module moved for compatibility with build 806
#  endif
#  if defined(__hpux)
Avoid signal flag SA_RESTART for older versions of HP-UX
#  endif
PerlEx hacks for CGI::Carp
Less verbose ExtUtils::Install and Pod::Find
instmodsh upgraded from ExtUtils-MakeMaker-6.25
24699 ICMP_UNREACHABLE handling in Net::Ping
21540 Fix backward-compatibility issues in if.pm

---
@INC for perl v5.8.7:
C:/Perl/lib
C:/Perl/site/lib
.

---
Environment for perl v5.8.7:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=c:\programme\imagemagick-6.2.4-q16;C:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\Programme\UltraEdit;C:\Programme\Microsoft
 SQL Server\80\Tools\BINN;C:\Tools;C:\Programme\Gemeinsame 
Dateien\GTK\2.0\bin;C:\Programme\Mts
PERL_BADLANG (unset)
SHELL (unset)




[perl #37036] perl segfault at 'compile'-time

2005-08-31 Thread Steve Peters via RT
 [EMAIL PROTECTED] - Wed Aug 31 01:38:30 2005]:
 
 
 This is a bug report for perl from [EMAIL PROTECTED],
 generated with the help of perlbug 1.35 running under perl v5.8.7.
 
 
 -
 Hi, i've found a small code that triggers a segfault on the
 following perl versions :
 
 5.8.4 (ubuntu package)
 5.8.7 (debian testing package)
 5.8.7 (freebsd port 5.3-RELEASE)
 5.9.1 (compiled on my linux debian testing i386, gcc-4.0.1)
 
 unaffected versions :
 version 5.005_03 built for sun4-solaris
 
 Priority is low, since this code is incorrect, but it might help
 resolving other issues.
 
 the segfault does not appear when not using 'strict'.
 note that no code is executed since it's in a sub that is never
 called at runtime.
 
 -- CODE BEGINS HERE --
 #!/usr/bin/perl
 use strict;
 sub s { open $X, my $Y, r; }
 -- CODE ENDS HERE --
 

This appears to have been fixed in bleadperl.  I'm not sure, though,
what the exact fix was.  Using perl-current, I get:

 ./perl -Mstrict -wle'sub s { open $X, my $Y, r; }'
Global symbol $X requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

In the 5.8 releases, the coredump occurs in Perl_ck_open.

#0  0x0809964c in Perl_ck_open ()
(gdb) bt
#0  0x0809964c in Perl_ck_open ()
#1  0x08092698 in Perl_convert ()
#2  0x08089336 in Perl_yyparse ()
#3  0x0806731a in Perl_my_failure_exit ()
#4  0x08068d0e in perl_parse ()
#5  0x0805fda9 in main ()



Re: [perl #37036] perl segfault at 'compile'-time

2005-08-31 Thread Dominic Dunlop

Summary: already fixed by patch 24523.

On 2005–08–31, at 10:38, [EMAIL PROTECTED] (via RT) wrote:


-- CODE BEGINS HERE --
#!/usr/bin/perl
use strict;
sub s { open $X, my $Y, r; }
-- CODE ENDS HERE --
[crashes on 5.8.x, 5.9.1]


FWIW, I see the crash (on Darwin) with 5.8.1-7 (omitting 5.8.2, which  
I don't have lying around) and 5.9.2, but not with [EMAIL PROTECTED]  
Stack trace for the crashed perls is like


Thread 0 Crashed:
0   perl 0x0002893c Perl_ck_open + 452 (op.c:5835)
1   perl 0x00017624 Perl_convert + 452 (op.c:2131)
2   perl 0x001adc60 Perl_yyparse + 8252 (perly.y:427)
3   perl 0x00033018 S_parse_body + 6184 (perl.c:1733)
4   perl 0x000315a4 perl_parse + 1780 (perl.c:1203)
5   perl 0x28b8 main + 308 (perlmain.c:97)
6   perl 0x1fe0 _start + 344 (crt.c:272)
7   perl 0x1e84 start + 60

(That happens to be 5.9.2; others are similar.)

A sniff of the blame log shows that patch 24523 did a little consting  
in that area. Reverting the changed lines in bleadperl brings the  
crash back. So consting fixed a bug that hadn't even been reported!


Does consting stuff like this get rolled into the various maints as a  
matter of course?

--
Dominic Dunlop



[perl #37039] perlref documentation about optional - is too vague

2005-08-31 Thread via RT
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #37039]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37039 



This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.4.


-
[Please enter your report here]

In 'perlref', item #3 of 'Using References' says

  One more thing here.  The arrow is optional between brackets sub-
  scripts, so you can shrink the above down to

$array[$x]{foo}[0] = January;

This led me to believe I could write:

  sub foo { ...; return @data }

  my $x = (foo())[0][1];

which would have the same effect as

  my @return = foo();
  my $x = $return[0][1];

However, it's a syntax error.  This can be fixed with an arrow:

  my $x = (foo())[0]-[1];

The problem is that (foo())[0] is NOT analogous to $array[$x]; one is a 
list slice, the other is a single element from an array.  But the 
documentation does not distinguish when it says optional between brackets 
subscripts [sic].

I think the language there should be polished a bit.

[Please do not change anything below this line]
-
---
Flags:
category=docs
severity=medium
---
Site configuration information for perl v5.8.4:

Configured by Debian Project at Mon Oct 25 01:52:37 EST 2004.

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
  Platform:
osname=linux, osvers=2.4.27-ti1211, archname=i386-linux-thread-multi
uname='linux kosh 2.4.27-ti1211 #1 sun sep 19 18:17:45 est 2004 i686 
gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN 
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr 
-Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr 
-Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 
-Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.4 
-Dsitearch=/usr/local/lib/perl/5.8.4 -Dman1dir=/usr/share/man/man1 
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl 
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib 
-Dlibperl=libperl.so.5.8.4 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define 
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN 
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN 
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-1)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.4
gnulibc_version='2.3.2'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:


---
@INC for perl v5.8.4:
/home/japhy/lib/share/perl/5.8.4
/home/japhy/lib/share/perl/5.8.3
/home/japhy/lib/share/perl
/etc/perl
/usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
/usr/local/lib/perl/5.8.3
/usr/local/share/perl/5.8.3
/usr/local/lib/perl/5.8.0
/usr/local/share/perl/5.8.0
.

---
Environment for perl v5.8.4:
HOME=/home/japhy
LANG=C
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/usr/local/bin:/usr/bin:/usr/ucb:/usr/sbin:/usr/openwin/bin:/bin:/usr/local/netscape:/usr/ccs/bin:/home/japhy/bin:.:/home/japhy/ICG/home/japhy/bin:/home/japhy/perl6/ghc-6.4/bin/i386-unknown-linux
PERL5LIB=/home/japhy/lib/share/perl
PERL_BADLANG (unset)
SHELL=/bin/tcsh



[perl #37036] perl segfault at 'compile'-time

2005-08-31 Thread Steve Peters via RT
 [EMAIL PROTECTED] - Wed Aug 31 06:01:12 2005]:
 
 Summary: already fixed by patch 24523.
 
 On 2005–08–31, at 10:38, [EMAIL PROTECTED] (via RT) wrote:
 
  -- CODE BEGINS HERE --
  #!/usr/bin/perl
  use strict;
  sub s { open $X, my $Y, r; }
  -- CODE ENDS HERE --
  [crashes on 5.8.x, 5.9.1]
 
 FWIW, I see the crash (on Darwin) with 5.8.1-7 (omitting 5.8.2, which  
 I don't have lying around) and 5.9.2, but not with [EMAIL PROTECTED]  
 Stack trace for the crashed perls is like
 
 Thread 0 Crashed:
 0   perl 0x0002893c Perl_ck_open + 452 (op.c:5835)
 1   perl 0x00017624 Perl_convert + 452 (op.c:2131)
 2   perl 0x001adc60 Perl_yyparse + 8252 (perly.y:427)
 3   perl 0x00033018 S_parse_body + 6184 (perl.c:1733)
 4   perl 0x000315a4 perl_parse + 1780 (perl.c:1203)
 5   perl 0x28b8 main + 308 (perlmain.c:97)
 6   perl 0x1fe0 _start + 344 (crt.c:272)
 7   perl 0x1e84 start + 60
 
 (That happens to be 5.9.2; others are similar.)
 
 A sniff of the blame log shows that patch 24523 did a little consting  
 in that area. Reverting the changed lines in bleadperl brings the  
 crash back. So consting fixed a bug that hadn't even been reported!
 
 Does consting stuff like this get rolled into the various maints as a  
 matter of course?
 

This seems to go a bit deeper.  My current bleadperl works fine on
OpenBSD, but segfaults on Linux.  I'll have to play with the
configurations to see what the backtrace from Linux will show me now.


Re: [perl #37038] Global regular matches generate invalid pointers

2005-08-31 Thread demerphq
On 8/31/05, via RT Thilo Girmann [EMAIL PROTECTED] wrote:
 # New Ticket Created by  Thilo Girmann
 # Please include the string:  [perl #37038]
 # in the subject line of all future correspondence about this issue.
 # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37038 
 
 
 
 This is a bug report for perl from [EMAIL PROTECTED],
 generated with the help of perlbug 1.35 running under perl v5.8.7.
 
 
 -
 [Please enter your report here]
 
 (I'm sending this message again using a mail client as it appears
 to me that it wasn't delivered by sendmail)
 
 When:
 * doing a global regular match
 * using $1 $2 etc. to retrieve extracted substrings
 * the original string does not exist any longer
 
 then $1 $2 etc. is pointing to an unallocated piece of memory.
 This way it's possible to return Perl's internal data structures
 if the piece of memory got re-used and possibly also cause Perl
 to crash if that piece of memory has been returned to the
 operating system.
 
 Here's a simple example to confirm the bug (tested under Windows
 NT / ActivePerl 5.8.7 and Linux 2.4 / Perl 5.8.0):
 
 use strict;
 use warnings;
 my $s = abcd;
 $s =~ /(..)(..)/g;
 $s = $1;
 $s = $2;
 print $s\n;
 
 
 The statement $s = $1 causes Perl to re-use the string abcd
 for storing the first half (ab) and add a terminating zero.
 $2 still points to the original second half but the character
 c got overwritten neanwhile.
 
 So if the bug is present you will get  c or just c printed
 out instead of the expected cd.

I can confirm this behaviour is in 5.8.6 and 5.6.1 on Win32.

yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/


Re: Fw: Re: [PATCH] Re: Transliteration operator(tr//)on EBCDIC platform

2005-08-31 Thread Sastry
Hi Sadahiro
  The patch has resolved four tests that were failing previously but one 
more test is stilling failing(which was failing even before applying the 
patch).
 Here is the test case
 
($a = v300.196.172.302.197.172) =~ tr/\x{12c}-\x{130}/\xc0-\xc4/;
is($a, v192.196.172.194.197.172, 'UTF range');
 # got 'DÐDEÐ'
# expected '{DÐBEÐ'
 Can you suggest some pointers towards fixing this?
 -Sastry
 On 8/16/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote: 
 
 perl5 porters,
 
 There is a response in approval from Sastry to my proposed patch.
 I'll forward it and now submit the proposal (on my prev mail) to p5p.
 
 Regards,
 SADAHIRO Tomoyuki
 
 Forwarded by SADAHIRO Tomoyuki [EMAIL PROTECTED]
 --- Original Message ---
 From: Sastry [EMAIL PROTECTED]
 To: SADAHIRO Tomoyuki [EMAIL PROTECTED]
 Date: Tue, 16 Aug 2005 15:27:45 +0530
 Subject: Re: [PATCH] Re: Transliteration operator(tr//)on EBCDIC platform
 
 
 Hi
 The patch works now as expected.
 
 Thanks
 -Sastry
 
 
 On 8/11/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
 
  On Wed, 10 Aug 2005 23:56:31 -0700 (PDT), rajarshi das 
 [EMAIL PROTECTED] wrote
 
   Hi,
   This is Rajarshi expressing Sastry's viewpoints since he's on 
 vacation.
  
   SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
  
   According to the above statement in perlebcdic.pod,
   s/[\x89-\x91]/X/g must substitute \x8e with X.
   But it doesn't concern whether tr/\x89-\x91/X/ would substitute \x8e
   with X or not, since tr/// does not use brackets, [ ].
  
   Though I think ranges in [ ] and ranges in tr/// should coincide
   and agree that tr/\x89-\x91/X/ should substitute \x8e with X,
   that is just my opinion.
   I don't know whether it is true and correct.
   Is there some way we can confirm if this is correct (and expected 
 behaviour)
   since there isnt any explicit documentation for the tr operator ?
 
  Since t/op/tr.t already has a test case (cf. Change 9038)
  which Sastry previously pointed out its failing on EBCDIC Platform,
  I assume that at least the then pumpking thought it to be correct.
 
   By the way, when you say If I specify [\x89-\x91], does it
   mean s/[\x89-\x91]/X/g or tr/\x89-\x91/X/ ? I'm confused.
   We mean tr/\x89-\x91/X/.
  
  
   We are first informed by you that gapped characters are not
   substituted with X by tr/\x89-\x91/X/.
   And you said s/[\x89-\x91]/X/g substituted all the characters
   including gapped characters with X, hadn't you?
  
   Yes.
   If so, I assume your [\x89-\x91] which doesn't matching any of
   the gapped characters to be tr/\x89-\x91/X/.
   That's correct. We mean tr/\x89-\x91/X/.
  
  
   The following is a part of the current core tests from op/pat.t.
   I believe they should be passed.
   Yes all the following tests pass. I think the following tests are in 
 the context of the
   s/[]/X/ operator and hence pass.
  
   Thanks,
  
   Rajarshi.
 
  OK. To me, it is confirmed that s/[]/X/ is fine and tr/// has a problem.
  Since I don't have any EBCDIC machine, I can't ensure the following
  patch will really makes sense.
 
  Regards,
  SADAHIRO Tomoyuki
 
  ! t/op/tr.t, toke.t
 
  diff -ur perl~/t/op/tr.t perl/t/op/tr.t
  --- perl~/t/op/tr.t Mon Aug 01 17:17:24 2005
  +++ perl/t/op/tr.t Thu Aug 11 23:41:22 2005
  @@ -295,18 +295,15 @@
  # (i-j, r-s, I-J, R-S), [\x89-\x91] [\xc9-\xd1] has to match them,
  # from Karsten Sperling.
 
  -# Not working in EBCDIC as of 12674.
  $c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91/X/;
  is($c, 8);
  is($a, );
  -
  -# Not working in EBCDIC as of 12674.
  +
  $c = ($a = \xc9\xca\xcb\xcc\xcd\xcf\xd0\xd1) =~ tr/\xc9-\xd1/X/;
  is($c, 8);
  is($a, );
 
  -
  -SKIP: {
  +SKIP: {
  skip not EBCDIC, 4 unless $Is_EBCDIC;
 
  $c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/i-j/X/;
  diff -ur perl~/toke.c perl/toke.c
  --- perl~/toke.c Mon Jul 18 04:31:02 2005
  +++ perl/toke.c Thu Aug 11 22:55:18 2005
  @@ -1368,6 +1368,9 @@
  I32 has_utf8 = FALSE; /* Output constant is UTF8 */
  I32 this_utf8 = UTF; /* The source string is assumed to be UTF8 */
  UV uv;
  +#ifdef EBCDIC
  + UV literal_endpoint = 0;
  +#endif
 
  const char *leaveit = /* set of acceptably-backslashed characters */
  PL_lex_inpat
  @@ -1417,8 +1420,9 @@
  }
 
  #ifdef EBCDIC
  - if ((isLOWER(min)  isLOWER(max)) ||
  - (isUPPER(min)  isUPPER(max))) {
  + if (literal_endpoint == 2 
  + ((isLOWER(min)  isLOWER(max)) ||
  + (isUPPER(min)  isUPPER(max {
  if (isLOWER(min)) {
  for (i = min; i = max; i++)
  if (isLOWER(i))
  @@ -1437,6 +1441,9 @@
  /* mark the range as done, and continue */
  dorange = FALSE;
  didrange = TRUE;
  +#ifdef EBCDIC
  + literal_endpoint = 0;
  +#endif
  continue;
  }
 
  @@ -1455,6 +1462,9 @@
  }
  else {
  didrange = FALSE;
  +#ifdef EBCDIC
  + literal_endpoint = 0;
  +#endif
  }
  }
 
  @@ -1788,6 +1798,10 @@
  s++;
  continue;
  } /* end if (backslash) */
  +#ifdef EBCDIC
  + else
  + literal_endpoint++;
  +#endif
 
  

Re: [perl #37036] perl segfault at 'compile'-time

2005-08-31 Thread Rafael Garcia-Suarez
[EMAIL PROTECTED] (via RT) wrote:
 Priority is low, since this code is incorrect, but it might help
 resolving other issues.
 
 the segfault does not appear when not using 'strict'.
 note that no code is executed since it's in a sub that is never
 called at runtime.
 
 -- CODE BEGINS HERE --
 #!/usr/bin/perl
 use strict;
 sub s { open $X, my $Y, r; }
 -- CODE ENDS HERE --

Thanks for the report, fixed as below in the development version of
perl:

Change 25341 by [EMAIL PROTECTED] on 2005/08/31 14:14:21

Fix for [perl #37036] perl segfault at 'compile'-time

Affected files ...

... //depot/perl/op.c#702 edit

Differences ...

 //depot/perl/op.c#702 (text) 

@@ -5896,6 +5896,7 @@
 (last-op_private  OPpCONST_STRICT) 
 (oa = first-op_sibling) /* The fh. */
 (oa = oa-op_sibling)/* The mode. */
+(oa-op_type == OP_CONST) 
 SvPOK(((SVOP*)oa)-op_sv) 
 (mode = SvPVX_const(((SVOP*)oa)-op_sv)) 
 mode[0] == ''  mode[1] == '' /* A dup open. */



Re: [perl #36848] Sys::Syslog::syslog kills program if syslogd not running

2005-08-31 Thread Rafael Garcia-Suarez
Ed Ravin wrote:
 
 In that case, we have a documentation bug - the fact that Sys::Syslog might
 crash the calling program with croak() is not mentioned in its man page.
 
 Would you accept patches for a nocroak or nofatal option to be used
 in Sys::Syslog::openlog() to disable the fatal exit behavior?

I applied the following to bleadperl :

Change 25342 by [EMAIL PROTECTED] on 2005/08/31 15:14:28

Document that Sys::Syslog::openlog might die.
Fixes [perl #36848] Sys::Syslog::syslog kills program if syslogd not 
running 

Affected files ...

... //depot/perl/ext/Sys/Syslog/Syslog.pm#29 edit

Differences ...

 //depot/perl/ext/Sys/Syslog/Syslog.pm#29 (text) 

@@ -53,13 +53,15 @@
 
 =item openlog $ident, $logopt, $facility
 
+Opens the syslog.
 I$ident is prepended to every message.  I$logopt contains zero or
 more of the words Ipid, Indelay, Inowait.  The cons option is
 ignored, since the failover mechanism will drop down to the console
 automatically if all other media fail.  I$facility specifies the
 part of the system to report about, for example LOG_USER or LOG_LOCAL0:
 see your Csyslog(3) documentation for the facilities available in
-your system.
+your system. This function will croak if it can't connect to the syslog
+daemon.
 
 BYou should use openlog() before calling syslog().
 


Re: [perl #36848] [RESOLVED] Sys::Syslog::syslog kills program if syslogd not running

2005-08-31 Thread Ed Ravin
On Wed, Aug 31, 2005 at 08:42:04AM -0700, Rafael Garcia-Suarez via RT wrote:
 According to our records, your request regarding 
   Sys::Syslog::syslog kills program if syslogd not running 
 has been resolved. 
 
 If you have any further questions or concerns, please respond to this message.

It looks like no action was taken.  I think at the very least, the behavior
that I complained about should be documented in the Syslog.pm man page.


Re: [perl #36848] Sys::Syslog::syslog kills program if syslogd not running

2005-08-31 Thread Ed Ravin
On Wed, Aug 31, 2005 at 09:01:57AM -0700, Rafael Garcia-Suarez via RT wrote:
 Ed Ravin wrote:
  
  In that case, we have a documentation bug - the fact that Sys::Syslog might
  crash the calling program with croak() is not mentioned in its man page.
  
  Would you accept patches for a nocroak or nofatal option to be used
  in Sys::Syslog::openlog() to disable the fatal exit behavior?
 
 I applied the following to bleadperl :

Thanks!


Re: IO::* indexing on PAUSE

2005-08-31 Thread Graham Barr

On Aug 29, 2005, at 15:16 PM, Andreas J. Koenig wrote:
I suggest PAUSE remove IO-1.20 as authoritive for the IO::*[3]  
modules

and let them be indexed as 'core' instead.


Is there no volunteer to roll a new IO-X.XX.tar.gz? That would resolve
the issue in the way that has been considered the superior around 2002


I will do it in the new few days. The reason I had not before was  
because

so many changes in the core depend on = 5.6.1, but I will just add that
as a restriction to IO-1.21

Graham.



advice needed for lib/File/Copy.t dates not preserved on VMS

2005-08-31 Thread John E. Malmberg
Test 20 of lib/File/Copy.t is failing on VMS because the copied file has 
not inherited the creation date from the original file.


This is consistent with the way that the COPY command works from the DCL 
command shell on VMS.


While I can change VMS to follow this behavior, I am concerned that it 
could break things.


Also, nothing in the documentation at 
http://perldoc.perl.org/File/Copy.html indicates that the new file would 
be created with the dates associated with the new file.  So I am curious 
why this test is even being done.


My copy of LINUX IN A NUTSHELL also indicates that having the 
destination file get the original file's attributes is not the default 
behavior of the cp command.


-John
[EMAIL PROTECTED]
Personal Opinion Only


Re: advice needed for lib/File/Copy.t dates not preserved on VMS

2005-08-31 Thread Craig A. Berry
At 7:51 PM -0400 8/31/05, John E. Malmberg wrote:
Test 20 of lib/File/Copy.t is failing on VMS because the copied file has not 
inherited the creation date from the original file.

Unless I'm looking at the wrong test, it's not creation time, but
rather mtime, which is the last time the contents of the file were
modified (probably ATR$C_REVDATE unless POSIX timestamps are enabled
on an ODS-5 disk).  And even though the test description says mtime
preserved by copy(), it's not testing copy() but rather move().  If
you simply rename a file, it does seem that mtime ought to stay the
same.  Not sure why that's not working on VMS.
-- 

Craig A. Berry
mailto:[EMAIL PROTECTED]

... getting out of a sonnet is much more
 difficult than getting in.
 Brad Leithauser