Re: [perl #36569] chop fails on decoded string with trailing nul
On Mon, 18 Jul 2005 20:33:28 -0700, Yitzchak Scott-Thoennes <[EMAIL PROTECTED]> wrote: > On Sat, Jul 16, 2005 at 03:48:10PM +0200, H.Merijn Brand wrote: > > On Sat, 16 Jul 2005 22:05:13 +0900, SADAHIRO Tomoyuki <[EMAIL PROTECTED]> > > > utf8_to_uvchr((U8*)s, 0) used in do_chop() returns 0, > > > not only if the octet sequence from *s is malformed, > > > but also if *s == '\0'. The return value 0 should be > > > for U+ (NUL) rather than malformedness. Oops :-< > > > > > > P.S. by the way, when the string in utf8 ends with malformed > > > octet(s), how should chop() do? > > > It has returned undef without modification of the string. > > > > Seems reasonable, though just cutting off one byte of the string would > > maybe more of an expected behaviour. Maybe > > Was there more to that sentence? No, I stopped after maybe. Because the more I thought about it, the less certain I was about *any* opinion I might have. I decided to leave that to the utf8 experts > I'd vote for removing and returning a malformed char, from the last > non continuation byte on (or just the unexpected continuation bytes, > if the problem was too many of them). > > That way, the data error is propagated onto the return value (as IMO > it should be), and a full-buffer problem will result in at most one > bad char. In fact, I could see being able to rely on this being > advantageous to buffering code (both XS and perl): > >fill buffer with bytes >chop char and set aside >process buffer >move choped char to start of buffer >repeat -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11, AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: [PATCH] Final (hopefully) fix for fchdir
On Mon, 18 Jul 2005 22:59:19 -0500, Steve Peters <[EMAIL PROTECTED]>
wrote:
> I noticed the blead's were still failing for HP-UX and AIX and ran a
> few tests on HP testdrive systems to see what was happening. There is
> a syntax error in code that did not previously compile. Below is the
> patch that will compile on HP-UX.
Thanks, applied as change #25178
> Enjoy,
>
> Steve Peters
> [EMAIL PROTECTED]
>
> --- pp_sys.c.old2005-07-18 12:03:27.0 -0500
> +++ pp_sys.c2005-07-18 22:55:54.0 -0500
> @@ -3592,7 +3592,7 @@
> #ifdef HAS_DIRFD
> PUSHi(fchdir(dirfd(IoDIRP(io))) >= 0);
> #else
> - DIE(aTHX PL_no_func, "dirfd");
> + DIE(aTHX_ PL_no_func, "dirfd");
> #endif
> }
> else {
>
>
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],perl-qa@perl.org
[PATCH] Final (hopefully) fix for fchdir
I noticed the blead's were still failing for HP-UX and AIX and ran a
few tests on HP testdrive systems to see what was happening. There is
a syntax error in code that did not previously compile. Below is the
patch that will compile on HP-UX.
Enjoy,
Steve Peters
[EMAIL PROTECTED]
--- pp_sys.c.old2005-07-18 12:03:27.0 -0500
+++ pp_sys.c2005-07-18 22:55:54.0 -0500
@@ -3592,7 +3592,7 @@
#ifdef HAS_DIRFD
PUSHi(fchdir(dirfd(IoDIRP(io))) >= 0);
#else
- DIE(aTHX PL_no_func, "dirfd");
+ DIE(aTHX_ PL_no_func, "dirfd");
#endif
}
else {
Re: [perl #36569] chop fails on decoded string with trailing nul
On Sat, Jul 16, 2005 at 03:48:10PM +0200, H.Merijn Brand wrote: > On Sat, 16 Jul 2005 22:05:13 +0900, SADAHIRO Tomoyuki <[EMAIL PROTECTED]> > wrote: > > > > This is a bug report for perl from [EMAIL PROTECTED], > > > generated with the help of perlbug 1.35 running under perl v5.8.4. > > > > > > I ran into this, and wondered if it is a bug. > > > > > > I have tested on perl 5.8.4 with Encode.pm version 1.99_01 (from > > > Debian package) and 2.10 (from CPAN). > > > > Thanks for the report. > > Thanks for the fast patch. Applied as change #25158 > > > utf8_to_uvchr((U8*)s, 0) used in do_chop() returns 0, > > not only if the octet sequence from *s is malformed, > > but also if *s == '\0'. The return value 0 should be > > for U+ (NUL) rather than malformedness. Oops :-< > > > > P.S. by the way, when the string in utf8 ends with malformed > > octet(s), how should chop() do? > > It has returned undef without modification of the string. > > Seems reasonable, though just cutting off one byte of the string would maybe > more of an expected behaviour. Maybe Was there more to that sentence? I'd vote for removing and returning a malformed char, from the last non continuation byte on (or just the unexpected continuation bytes, if the problem was too many of them). That way, the data error is propagated onto the return value (as IMO it should be), and a full-buffer problem will result in at most one bad char. In fact, I could see being able to rely on this being advantageous to buffering code (both XS and perl): fill buffer with bytes chop char and set aside process buffer move choped char to start of buffer repeat
Re: [PATCH] perlop: why \c\ cannot be placed just before the terminating delimiter
On Sun, Jul 17, 2005 at 11:38:05AM +0900, SADAHIRO Tomoyuki wrote: > Hello, > > \c\ is an only case (afaik) of escape sequence ending with backslash. > Though perlop explains how to find the end of quoted constructs > in detail, it may be a trap. > > Regards, > SADAHIRO Tomoyuki > > diff -ur perl~/pod/perlop.pod perl/pod/perlop.pod > --- perl~/pod/perlop.pod Fri Jul 15 18:33:32 2005 > +++ perl/pod/perlop.pod Sun Jul 17 10:50:41 2005 > @@ -1668,6 +1668,11 @@ > the example above is not C, but rather C with no C > modifier. So the embedded C<#> is interpreted as a literal C<#>. > > +Also no attention is paid to C<\c\> during this search. > +Thus the second C<\> in C is interpleted as a part of C<\/>, > +and the following C is not recognized as delimiter. > +Instead, use C<\034> or C<\x1c> at the end of quoted constructs. > + > =item Removal of backslashes before delimiters > > During the second pass, text between the starting and ending > END OF PATCH I've long considered this a bug. I'd rather not document it, or document it explicitly as a bug. IMO "finding the end" is inconsistent with later processing, and \c\ should be treated as a complete character.
Re: [PATCH] Faster **
On Fri, Jun 24, 2005 at 12:47:40PM +0200, Piotr Fusik wrote: > > Due to recent codes changes (cleanup, variable declaration moved) in this > > part, your patch doesn't apply cleanly. Can you resubmit one against a > > more recent bleadperl ? > > No problem. Thanks, applied as change #25177 -- In the 70's we wore flares because we didn't know any better. What possible excuse does the current generation have?
Re: ignoring close failures
On Sat, Jul 02, 2005 at 10:26:41PM +0100, Nicholas Clark wrote:
> This bit of Perl_sv_clear is generating a compiler warning now:
>
> case SVt_PVIO:
> if (IoIFP(sv) &&
> IoIFP(sv) != PerlIO_stdin() &&
> IoIFP(sv) != PerlIO_stdout() &&
> IoIFP(sv) != PerlIO_stderr())
> {
> io_close((IO*)sv, FALSE);
> }
>
>
> Should we really be ignoring close failure here? Would it be better to
> issue a lexical warning? If so, what category? And what text?
I think people doing an implicit close don't care whether it succeeds,
so the return status should just be quietly ignored.
--
Counsellor Troi states something other than the blindingly obvious.
-- Things That Never Happen in "Star Trek" #16
Re: [perl #17650] [PATCH] DESTROY can prevent propagation of die
On Mon, Jul 18, 2005 at 01:14:43AM -0400, Alex Vandiver wrote:
> On Sun, 2005-07-10 at 14:29 +0100, Dave Mitchell wrote:
> > I don't think this fix is robust. You save the current PV value of ERRSV,
> > and then later set it back; in the meantime, ERRSV's PV may have been
> > realloced, and message now points to free or realloced garbage.
> Point. The attached patch uses save_item(ERRSV) to fully localize [EMAIL
> PROTECTED]
> Also added more tests that the previous patch didn't pass on. Thoughts?
> - Alex
I like the idea of localising $@ before calling DESTROY, but unfortunately
it breaks this test:
lib/warnings..PROG:
# pp_ctl.c
use warnings 'misc' ;
package Foo;
DESTROY { die "@{$_[0]} foo bar" }
{ bless ['A'], 'Foo' for 1..10 }
{ bless ['B'], 'Foo' for 1..10 }
EXPECTED:
(in cleanup) A foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
GOT:
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) A foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
(in cleanup) B foo bar at - line 4.
# Failed at ../lib/warnings.t line 186
The behaviour being tested here is that a die in a DESTROY gets converted
to a warn with an (in cleanup) prefix, and that subsequent massages with
the same suffix should be suppressed. The current supression mechanism
relies on comparing the new message with the current value of ERRSV.
I'm not really sure offhand of the best way round this. Perhaps have an
extra PL_ var that holds the hash of the last (in cleanup) warning ???
--
My Dad used to say 'always fight fire with fire', which is probably why
he got thrown out of the fire brigade.
Smoke [5.9.3] 25174 FAIL(M) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
Automated smoke report for 5.9.3 patch 25174 TANGAROA.uk.radan.com: Intel(R) Pentium(R) 4 CPU 2.00GHz(~1992 MHz) (x86/1 cpu) onMSWin32 - WinXP/.Net SP1 using cl version 12.00.8804 smoketime 1 hour 43 minutes (average 4 minutes 18.208 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 25174 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - M M M M -Dusemymalloc M M -Duselargefiles M M -Duselargefiles -Dusemymalloc M M -Duseithreads M M -Duseithreads -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' M M -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Failures: (common-args) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist [minitest] [minitest] -DDEBUGGING [minitest] -Dusemymalloc [minitest] -DDEBUGGING -Dusemymalloc [minitest] -Duselargefiles [minitest] -DDEBUGGING -Duselargefiles [minitest] -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 op/magic..dubious DIED. FAILED tests 43-58 op/utftaint...dubious [minitest] -Duseithreads [minitest] -DDEBUGGING -Duseithreads [minitest] -Duseithreads -Duselargefiles [minitest] -DDEBUGGING -Duseithreads -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 op/fork...FAILED tests 1-19 op/magic..dubious DIED. FAILED tests 43-58 op/threadsdubious DIED. FAILED tests 1-3 op/utftaint...dubious -- Report by Test::Smoke v1.19_70 build 861 running on perl 5.8.7 (Reporter v0.021 / Smoker v0.024) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
[perl #36588] Problem with semctl() on Perl 5.8.6, 64-bit build, HP-UX 11i
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36588]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36588 >
This is a bug report for perl from [EMAIL PROTECTED], generated with
the help of perlbug 1.35 running under perl v5.8.6.
-
[Please enter your report here]
Hi,
I ran into a problem with semctl() on our Perl 5.8.6. SETVAL does
not seem to do the right thing. The call suceeds, but subsequent
calls to GETVAL and GETALL return 0, and an attempt to lock waits
forever. The code snippet below prints correct "1" on 32-bit build
of Perl 5.6.1, but prints incorrect "0" on 64-bit build of Perl
5.8.6.
use strict;
use IPC::SysV qw(IPC_NOWAIT SEM_UNDO S_IRWXU IPC_CREAT IPC_EXCL
SETVAL GETALL); my $InstanceLock = semget( 123456, 1,
S_IRWXU|IPC_CREAT|IPC_EXCL ); unless ($InstanceLock) { die "Failed
to create new semaphore: $!\n"; } print "Created new semaphore\n";
unless (semctl($InstanceLock,0,SETVAL,1)) { die "Failed to setval:
$!\n"; } my $data = ""; unless
(semctl($InstanceLock,0,GETALL,$data)) { die "Failed to getval:
$!\n"; } my @getall = unpack("s!*",$data); print @getall,"\n";
Output from 5.6.1 (32-bit):
Created new semaphore
1
Output from 5.8.6 (64-bit):
Created new semaphore
0
(Of course, I called ipcrm between the two tests to delete the
semaphore. I'm saying this just in case :-))
Thanks,
Petr Novotny
[EMAIL PROTECTED]
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=high
---
Site configuration information for perl v5.8.6:
Configured by urbang at Tue May 31 11:37:17 METDST 2005.
Summary of my perl5 (revision 5 version 8 subversion 6)
configuration: Platform:
osname=hpux, osvers=11.11, archname=PA-RISC2.0-LP64
uname='hp-ux hpl2pdc b.11.11 u 9000800 179404641 unlimited-user
license ' config_args='-A prepend:libswanted=cl pthread
-Duse64bitall'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef useperlio=define d_sfio=undef
uselargefiles=define usesocks=undef use64bitint=define
use64bitall=define uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags =' -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings
+DD64 -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 ', optimize='+O2 +Onolimit',
cppflags='-Aa -D__STDC_EXT__ -D_HPUX_SOURCE -Ae -D_HPUX_SOURCE
-Wl,+vnocompatwarnings +DD64 -I/usr/local/include'
ccversion='B.11.11.08', gccversion='', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8,
byteorder=87654321 d_longlong=define, longlongsize=8,
d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8,
nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='/usr/bin/ld', ldflags =' +DD64 -L/usr/local/lib
-L/lib/pa20_64' libpth=/usr/local/lib /lib/pa20_64 /lib
/usr/lib /usr/ccs/lib
libs=-lcl -lpthread -lnsl -lnm -ldl -ldld -lm -lsec -lc
perllibs=-lcl -lpthread -lnsl -lnm -ldl -ldld -lm -lsec -lc
libc=/lib/pa20_64/libc.sl, so=sl, useshrplib=true,
libperl=libperl.sl gnulibc_version=''
Dynamic Linking:
dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-B,deferred ' cccdlflags='+Z', lddlflags='-b
+vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64'
Locally applied patches:
---
@INC for perl v5.8.6:
/usr/local/perl586/lib/5.8.6/PA-RISC2.0-LP64
/usr/local/perl586/lib/5.8.6
/usr/local/perl586/lib/site_perl/5.8.6/PA-RISC2.0-LP64
/usr/local/perl586/lib/site_perl/5.8.6
/usr/local/perl586/lib/site_perl
.
---
Environment for perl v5.8.6:
HOME=/pneusr.l2pdc/pne/dev/petrne
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH=/pneusr.l2pdc/pne/dev/petrne/proj/cmf550V64/lib:/pnechome/pne/ccpne/ccpne/proj/cmf550V64/lib:/usr/local64/gmp-4.1.2/lib::/oravl01/oracle/9.2.0.6/lib:/opt/cobol/cobdir/coblib:/opt/syncsort64.3.4/lib:/usr/lib/pa20_64:/usr/lib:/opt/TimesTen/tt5034_64/lib
LOGDIR (unset)
PATH=/usr/local/ccmngr_p/ccgnrl/v10/bin:/opt/imake/bin:/opt/java1.4/bin:/pnechome/pne/ccpne/ccpne/proj/gatl550V64/bin:/pnechome/pne/ccpne/ccpne/proj/ginftl550V64/bin:/oravl01/oracle/9.2.0.6:/oravl01/oracle/9.2.0.6/bin:/pneusr.l2pdc/pne/dev/petrne/proj/cmf550V64/bin:/pnechome/pne/ccpne/ccpne/proj/cmf550V64/bin:/pneusr.l2pdc/pne/dev/petrne/proj/gmf550V64/bin:/pnechome/pne/ccpne/ccpne/proj/gmf550V64/bin:/pnechome/pne/ccpne/ccpne/proj/ggen550V64/bin:/pneusr.l2pdc/pne/dev/petrne/proj/mfgdd550V64/bin:/pnechome/pne/ccpne/ccpne/proj/mfgdd550V64/bin:/usr/local/ccmngr_p/ccgnrl/v10/bin:/oravl01/oracle/9.2.0.6:/oravl01/oracle/9.2.0.6/bin:/pnechome/pne/ccpne/ccpne/proj/gatl550/bin:/pnechome/pne/ccpne/ccpne/proj/ginftl550/b
Re: your malloc patches
On Sun, Jun 15, 2003 at 09:14:16PM +0300, Jarkko Hietaniemi wrote: > > > This just isn't cricket for non-GCC compilers (Solaris, AIX, and Tru64 > > > claim a syntax error, IRIX seems to tolerate it). That a function > > > call (Perl_doing_taint in this case) gets expanded to func(a,b,) just > > > isn't going to work. (What does leaving out an argument like that > > > _mean_, anyway? An implicit 0?) > > > > It is a *macro*, not a function call! Macros operate on strings. An > > empty string is a perfectly valid string (though I do not know what > > When the macro gets expanded at the very beginning of main() we get this: > > if (Perl_doing_taint(*&argc, *&argv, )) > > which makes many C compilers to choke, but apparently not gcc. > > > the C standard says on this). > > > > Anyway, this slot is not used, so put there NOTUSED. > > I have no idea what you mean by NOTUSED. If you mean the trick you said: > > #define NOTUSED > #define MALLOC_CHECK_TAINT2(argc,argv) MALLOC_CHECK_TAINT(argc,argv,NOTUSED) > > That doesn't work since that gets expanded to exactly the same as above. A possible solution would be to use __VA_ARGS__. I'm not sure how portable this is between cpp implementations... it supposedly has worked with gcc since at least 2.95 (I haven't tried it with anything older than gcc 3.3) and it is part of C99. #define MALLOC_CHECK_TAINT2(argc,...) MALLOC_CHECK_TAINT(argc,__VA_ARGS__) -J -- pgpyhNhise674.pgp Description: PGP signature
Re: [perl #36586] $1 gets mysteriously unset when leaving 'for' block
On Mon, Jul 18, 2005 at 01:41:52AM -0700, avised @ kbcfp. com wrote:
> This test program:
>
> my $foo = 'foo';
> for ($foo) {
> m!(\w+)! or die;
> print "\$1 has been set to: $1\n";
> }
> print "\$1 is now: $1\n";
>
> gives the output:
>
> $1 has been set to: foo
> $1 is now:
>
> Somehow, although $1 was set it has been changed back to undef on
> exiting the 'for' block. I don't see anything in perlre or perlvar
> documenting this.
Feature, not bug.
>From perlre:
The numbered match variables ($1, $2, $3, etc.) and the related punctu-
ation set ($+, $&, $`, $', and $^N) are all dynamically scoped until
the end of the enclosing block or until the next successful match,
whichever comes first. (See "Compound Statements" in perlsyn.)
$1 and friends have an implicit "local" on them so they are localized to
a block. Its been this way for a long time.
$ perl5.4.5 -wle '$_ = "foo"; { /(\w)/; print $1 } print $1'
f
Use of uninitialized value at -e line 1.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
-- "Witches Abroad" by Terry Prachett
Re: Binary compatilibity of function ordering
On Mon, Jul 18, 2005 at 08:53:10AM -0500, Andy Lester wrote: > On Mon, Jul 18, 2005 at 11:19:45AM +0100, Nicholas Clark ([EMAIL PROTECTED]) > wrote: > > If this is true then we can re-order functions in embed.fnc to our heart's > > content in maint. > > Good, 'cause I already have a couple times. :-) I don't think they've got to maint. Nicholas Clark
Re: [perl #22312] Another self-modifyingloop bug
On Mon, Jul 18, 2005 at 08:37:14PM +0100, Dave Mitchell wrote: > The only question is whether it's worth the small slowdown of testing the > refcnt of $_ at each iteration? A good rule of thumb is "Perl should never kill perl" and any marginal slow down is worth hanging onto that. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: Circular dependency prevents installation of Scalar-List-Utils on 5.004
On Mon, Jul 18, 2005 at 02:30:27PM +0100, Paul Marquess wrote: > Is there any way out of this "maze of twisty little passages"? Install File::Spec by hand? Use 5.004_05 which comes with File::Spec? I think the assumption that Perl will come with File::Spec and Cwd is a fairly safe one these days except for pathologically old versions of Perl. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [perl #22312] Another self-modifyingloop bug
On Sun, Jul 17, 2005 at 03:55:28PM -0700, Michael G Schwern via RT wrote: > > [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. Not a lot we an do about this except to possibly do for 'map'/'grep' what I did with 'for'; and that is to put a test in for a freed value, and if so, bail out. It's not perfect, but it's usually better than an segfault: $ ./perl -we '@a=1..9; @a = () for @a,1' Use of freed value in iteration at -e line 1. $ The only question is whether it's worth the small slowdown of testing the refcnt of $_ at each iteration? -- You live and learn (although usually you just live).
Re: [PATCH] RE: blead: no longer supports %vd format
Rafael Garcia-Suarez wrote: >Steve Hay wrote: > > >>>Thanks, applied as change #25171 to bleadperl. >>> >>> >>> >>This change causes tons of warnings like >> >>not enough actual parameters for macro 'SVf_' >> >>on Win32. >> >>This is the bit of perl.h that causes them all: >> >>#ifndef SVf_ >># define SVf_(n) "-" #n "p" >>#endif >> >>#ifndef SVf >># define SVf SVf_() >>#endif >> >>Neither SVf_ nor SVf are initially defined, so you can see what the >>problem is. >> >>Can this be fixed? If not then perhaps revert that part of the change. >> >> > >You mean like this ? : look ok to me > Yep, that fixes it. Applied as 25174. (Thanks also to Robin who suggested the same fix.) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: AIX 5.2 localtime bug attack
On Mon, 18 Jul 2005 17:34:55 +0200, Campo Weijerman <[EMAIL PROTECTED]> wrote:
> > +/* This edge case is to workaround the undefined behaviour, where the
> > + * TIMEZONE makes the time go beyond the defined range.
> > + * gmtime (0x7fff) => 2038-01-19 03:14:07
> > + * If there is a negative offset in TZ, like MET-1METDST, some broken
> > + * implementations of localtime () (like AIX 5.2) barf with bogus
> > + * return values:
> > + * 0x7fff gmtime 2038-01-19 03:14:07
> > + * 0x7fff localtime1901-12-13 21:45:51
> > + * 0x7fff mylocaltime 2038-01-19 04:14:07
> > + * 0x3c19137f gmtime 2001-12-13 20:45:51
> > + * 0x3c19137f localtime2001-12-13 21:45:51
> > + * 0x3c19137f mylocaltime 2001-12-13 21:45:51
> > + * Given that legal timezones are typically between GMT-12 and GMT+12
> > + * we turn back the clock 23 hours before calling the localtime
> > + * function, and add those to the return value. This will never cause
> > + * day wrapping problems, since the edge case is Jan *19*
> > + */
> > +T = *tp - 82800; /* 23 hour. allows up to GMT-23 */
> > +P = localtime (&T);
> > +P->tm_hour += 23;
> > +if (P->tm_hour >= 24) {
> > + P->tm_hour -= 24;
> > + P->tm_mday++;
> > +}
>
> Well, it's not nice, but I suppose it should fix the boundary case.
> However, I think you should also increment these other fields along
> with tm_mday:
>
> int tm_wday;/* Day of week (Sunday = 0) */
> int tm_yday;/* Day of year (0 - 365) */
Both done now in #25173
> I'm not fond of this sort of struct tm manipulation. It's easy to
> get wrong, and then you have just replaced a known bug by an unknown
> one. Luckily, 2038-01-19 is supposed to be on a Tuesday, and we
> are sufficiently far away from the boundaries of the week, month, and
> year... Until someone starts using TZ=CUT-50, say :-(
As the surrounding comments already said.
By the time this workaround should be a problem, we are all on 64, 128 or
even 256 bit machines
As you can see, the bug is already safe for 64bit values, since the
workaround only acts in a small window:
+if (!tp || *tp < 0x7fff573f || *tp >= 0x8000)
+ return (localtime (tp));
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: fchmod, fchown, fchdir
On Mon, 18 Jul 2005 18:10:27 +0200, Campo Weijerman <[EMAIL PROTECTED]> wrote: > On Fri, Jul 15, 2005 at 02:32:50AM -0700, Gisle Aas wrote: > > +#ifdef HAS_DIRFD > > + PUSHi(fchdir(dirfd(IoDIRP(io))) >= 0); > > +#else > > + DIE(aTHX PL_no_func, "dirfd"); > > +#endif > > This might explain the smoke failures I was having on AIX, starting > from 25157. (last successful make was 25150) No, it does not. It just uncovered a bug in Configure, which I fixed in 25169, and the test case in 25170 > Perhaps I haven't looked hard enough, but there doesn't seem to be a > dirfd() on AIX, and Configure agrees: > > $ ./Configure -Dusedevel -des > [...] > dirfd() NOT found. > [...] > > $ grep -i dirfd conf* > config.h:/* HAS_DIRFD: > config.h: * This manifest constant lets the C program know that dirfd > config.h:/*#define HAS_DIRFD/ **/ > config.sh:d_dirfd='undef' > config_h.SH:/* HAS_DIRFD: > config_h.SH: * This manifest constant lets the C program know that dirfd > config_h.SH:#$d_dirfd HAS_DIRFD /**/ > configure.com:$ WC "d_dirfd='undef'" > > $ make > [...] > ld: 0711-317 ERROR: Undefined symbol: .dirfd > > But: > > $ ./Configure -Dusedevel -Ud_dirfd -des > > Works allright... > > So what's going on here? -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11, AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
RE: [PATCH] RE: blead: no longer supports %vd format
-Original Message- From: Steve Hay To: Rafael Garcia-Suarez Cc: Robin Barker; ''The Perl5 Porters Mailing List ''; John Peacock Sent: 18/07/05 17:26 Subject: Re: [PATCH] RE: blead: no longer supports %vd format Rafael Garcia-Suarez wrote: >On 7/14/05, Robin Barker <[EMAIL PROTECTED]> wrote: > > >>Attached patch reinstates VDf in blead perl to implement the >>%vd format, which is still used in XS code and will reappear >>in blead for ... > >Thanks, applied as change #25171 to bleadperl. > This change causes tons of warnings like not enough actual parameters for macro 'SVf_' on Win32. This is the bit of perl.h that causes them all: #ifndef SVf_ # define SVf_(n) "-" #n "p" #endif #ifndef SVf # define SVf SVf_() #endif Neither SVf_ nor SVf are initially defined, so you can see what the problem is. Can this be fixed? If not then perhaps revert that part of the change. - Steve I guess the problem is the lack of parameters to SVf_, gcc does not mind, and successfully defines SVf as "-p" The simple patch is (written by hand - can't do anything clever from home): Index: perl.h #endif #ifndef SVf -# define SVf SVf_() +# define SVf "-p" #endif #ifndef SVf32 End of patch Robin --- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY ---
Re: [PATCH] RE: blead: no longer supports %vd format
Steve Hay wrote: > >Thanks, applied as change #25171 to bleadperl. > > > This change causes tons of warnings like > > not enough actual parameters for macro 'SVf_' > > on Win32. > > This is the bit of perl.h that causes them all: > > #ifndef SVf_ > # define SVf_(n) "-" #n "p" > #endif > > #ifndef SVf > # define SVf SVf_() > #endif > > Neither SVf_ nor SVf are initially defined, so you can see what the > problem is. > > Can this be fixed? If not then perhaps revert that part of the change. You mean like this ? : look ok to me Index: perl.h === --- perl.h (révision 5460) +++ perl.h (copie de travail) @@ -2635,7 +2635,7 @@ #endif #ifndef SVf -# define SVf SVf_() +# define SVf "-p" #endif #ifndef SVf32
Re: [PATCH] RE: blead: no longer supports %vd format
Rafael Garcia-Suarez wrote: >On 7/14/05, Robin Barker <[EMAIL PROTECTED]> wrote: > > >>Attached patch reinstates VDf in blead perl to implement the %vd format, >>which is still used in XS code and will reappear in blead for read-only >>version numbers. >> >>I have taken the opportunity to tidy up the code for the %p hacks that >>are used to proved SVf (was %_) and VDf. The format processing code >>does an initial pass for %p "extensions" and then resumes the previous >>processing. I have also added some comments to describe the use of %p. >> >> > >Thanks, applied as change #25171 to bleadperl. > This change causes tons of warnings like not enough actual parameters for macro 'SVf_' on Win32. This is the bit of perl.h that causes them all: #ifndef SVf_ # define SVf_(n) "-" #n "p" #endif #ifndef SVf # define SVf SVf_() #endif Neither SVf_ nor SVf are initially defined, so you can see what the problem is. Can this be fixed? If not then perhaps revert that part of the change. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: fchmod, fchown, fchdir
On Fri, Jul 15, 2005 at 02:32:50AM -0700, Gisle Aas wrote: > +#ifdef HAS_DIRFD > + PUSHi(fchdir(dirfd(IoDIRP(io))) >= 0); > +#else > + DIE(aTHX PL_no_func, "dirfd"); > +#endif This might explain the smoke failures I was having on AIX, starting from 25157. (last successful make was 25150) Perhaps I haven't looked hard enough, but there doesn't seem to be a dirfd() on AIX, and Configure agrees: $ ./Configure -Dusedevel -des [...] dirfd() NOT found. [...] $ grep -i dirfd conf* config.h:/* HAS_DIRFD: config.h: * This manifest constant lets the C program know that dirfd config.h:/*#define HAS_DIRFD/ **/ config.sh:d_dirfd='undef' config_h.SH:/* HAS_DIRFD: config_h.SH: * This manifest constant lets the C program know that dirfd config_h.SH:#$d_dirfd HAS_DIRFD /**/ configure.com:$ WC "d_dirfd='undef'" $ make [...] ld: 0711-317 ERROR: Undefined symbol: .dirfd But: $ ./Configure -Dusedevel -Ud_dirfd -des Works allright... So what's going on here? -- $_ = "Campo Weijerman [rfc822://nl.ibm.com/]" and tr-[:]/-<@>-d and print;
Re: [PATCH] The continuing plod through embed.fnc
Andy Lester wrote: > Trying again Thanks, applied (#25172).
Re: [PATCH] The continuing plod through embed.fnc
Trying again > As always, make regen after application. > > * embed.fnc: Many additions of NN and NULLOK to pointers. I'm down to > 332 pointers yet to be explicitly specified, from about 480 last week. > > * op.c: One consting. > > * pad.c: Replaced "0" with "Nullch" > > * pp_sys.c: Localized some vars in pp_chdir, and removed repeated calls > to GvHVn, a complicated macro. Saves about 100 bytes of object code. > > * regcomp.c: One consting. > > * utf8.c: One consting. > > -- > Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance > -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance diff -pur bleadperl/embed.fnc bw/trunk/embed.fnc --- bleadperl/embed.fnc 2005-07-15 11:59:36.0 -0500 +++ bw/trunk/embed.fnc 2005-07-18 10:30:43.0 -0500 @@ -226,13 +226,13 @@ ApR |I32|dowantarray Ap |void |dump_all Ap |void |dump_eval #if defined(DUMP_FDS) -Ap |void |dump_fds |char* s +Ap |void |dump_fds |NN char* s #endif -Ap |void |dump_form |const GV* gv +Ap |void |dump_form |NN const GV* gv Ap |void |gv_dump|NN GV* gv Ap |void |op_dump|NN const OP* arg -Ap |void |pmop_dump |PMOP* pm -Ap |void |dump_packsubs |const HV* stash +Ap |void |pmop_dump |NULLOK PMOP* pm +Ap |void |dump_packsubs |NN const HV* stash Ap |void |dump_sub |NN const GV* gv Apd|void |fbm_compile|NN SV* sv|U32 flags ApdR |char* |fbm_instr |NN unsigned char* big|NN unsigned char* bigend \ @@ -266,10 +266,10 @@ Apd |GV*|gv_fetchmeth_autoload |HV* sta Apd|GV*|gv_fetchmethod |HV* stash|const char* name Apd|GV*|gv_fetchmethod_autoload|HV* stash|const char* name \ |I32 autoload -Ap |GV*|gv_fetchpv |const char* name|I32 add|I32 sv_type -Ap |void |gv_fullname|SV* sv|const GV* gv -Apmb |void |gv_fullname3 |SV* sv|const GV* gv|const char* prefix -Ap |void |gv_fullname4 |SV* sv|const GV* gv|const char* prefix|bool keepmain +Ap |GV*|gv_fetchpv |NN const char* name|I32 add|I32 sv_type +Ap |void |gv_fullname|NN SV* sv|NN const GV* gv +Apmb |void |gv_fullname3 |NN SV* sv|NN const GV* gv|NULLOK const char* prefix +Ap |void |gv_fullname4 |NN SV* sv|NN const GV* gv|NULLOK const char* prefix|bool keepmain Ap |void |gv_init|NN GV* gv|HV* stash|NN const char* name|STRLEN len|int multi Apd|HV*|gv_stashpv |const char* name|I32 create Apd|HV*|gv_stashpvn|const char* name|U32 namelen|I32 create @@ -447,18 +447,18 @@ Afp |SV*|mess |NN const char* pat|... Ap |SV*|vmess |NN const char* pat|NULLOK va_list* args p |void |qerror |SV* err Apd |void |sortsv |SV ** array|size_t num_elts|SVCOMPARE_t cmp -Apd|int|mg_clear |SV* sv -Apd|int|mg_copy|SV* sv|SV* nsv|const char* key|I32 klen -pd |void |mg_localize|SV* sv|SV* nsv +Apd|int|mg_clear |NN SV* sv +Apd|int|mg_copy|NN SV* sv|NN SV* nsv|const char* key|I32 klen +pd |void |mg_localize|NN SV* sv|NN SV* nsv ApdR |MAGIC* |mg_find|NULLOK const SV* sv|int type -Apd|int|mg_free|SV* sv -Apd|int|mg_get |SV* sv -Apd|U32|mg_length |SV* sv -Apd|void |mg_magical |SV* sv -Apd|int|mg_set |SV* sv -Ap |I32|mg_size|SV* sv -Ap |void |mini_mktime|struct tm *pm -p |OP*|mod|OP* o|I32 type +Apd|int|mg_free|NN SV* sv +Apd|int|mg_get |NN SV* sv +Apd|U32|mg_length |NN SV* sv +Apd|void |mg_magical |NN SV* sv +Apd|int|mg_set |NN SV* sv +Ap |I32|mg_size|NN SV* sv +Ap |void |mini_mktime|NN struct tm *pm +p |OP*|mod|NULLOK OP* o|I32 type p |int|mode_from_discipline|SV* discp Ap |char* |moreswitches |char* s p |OP*|my |NN OP* o @@ -499,7 +499,7 @@ Apa |OP*|newANONHASH|OP* o Ap |OP*|newANONSUB |I32 floor|OP* proto|OP* block Apa|OP*|newASSIGNOP|I32 flags|NULLOK OP* left|I32 optype|NULLOK OP* right Apa|OP*|newCONDOP |I32 flags|NN OP* first|NULLOK OP* trueop|NULLOK OP* falseop -Apd|CV*|newCONSTSUB|NULLOK HV* stash|NN const char* name|NULLOK SV* sv +Apd|CV*|newCONSTSUB|NULLOK HV* stash|NULLOK const char* name|NULLOK SV* sv Ap |void |newFORM|I32 floor|NULLOK OP* o|NULLOK OP* block Apa|OP*|newFOROP |I32 flags|char* label|line_t forline \ |OP* sclr|OP* expr|OP*block|OP*cont @@ -513,7 +513,7 @@ Apa |OP*|newRANGE |I32 flags|OP* left|O Apa|OP*|newSLICEOP |I32 flags|OP* subscript|OP* listop
[perl #18905] Using HTTP::Daemon with Perl 5.8.0 cuts off web pages on Win32
> [m0zart - Thu Dec 05 11:42:26 2002]: > > > This is a bug report for perl from [EMAIL PROTECTED] > generated with the help of perlbug 1.34 running under perl v5.8.0. > > > - > [Please enter your report here] > > I have used Perl 5.00503 and Perl 5.6.1 in combination with the > HTTP::daemon to run a single-connection webserver for a few years > now, and have never had a problem. Recently however, after > building Perl 5.8.0 for Win32, I ran into a severe problem. > After a web page is sent across, it gets truncated/cut-off by the > time it reaches the Browser. This happens for any browser, > whether it be Netscape or IE on Windows, or Netscape on UNIX. > > I downloaded the Perl 5.8.0 binary distribution, to see if > perhaps there was a build problem on my machine in particular, > but the exact same problem occurs. > > I thought this might be related to Ticket #16234, but setting the > environment variable "PERLIO" to ":raw" doesn't fix the problem. > The pages are actually losing A LOT of the webpages, between 2/3 > and 3/4. > > I am sending this to "core" rather than "libraries" because the > bug seems to be deeper in Perl's IO layer, rather than a part > of the HTTP/Daemon.pm module. > > NOTE: I also built Perl 5.8.0 for several UNIX platforms > (Solaris, DecAlpha, HPUX, AIX, Linux for x86, Linux for s390, > Reliant/Sinix, and Sequent/Dynix) and didn't have this problem > on any of those. > Without code to demonstrate this problem, it is difficult to say whether the problem is in the module or in the core. Do you have any code to demonstrate this problem?
[PATCH] The continuing plod through embed.fnc
As always, make regen after application. * embed.fnc: Many additions of NN and NULLOK to pointers. I'm down to 332 pointers yet to be explicitly specified, from about 480 last week. * op.c: One consting. * pad.c: Replaced "0" with "Nullch" * pp_sys.c: Localized some vars in pp_chdir, and removed repeated calls to GvHVn, a complicated macro. Saves about 100 bytes of object code. * regcomp.c: One consting. * utf8.c: One consting. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: AIX 5.2 localtime bug attack
On Fri, Jun 24, 2005 at 09:02:37AM +0200, H.Merijn Brand wrote:
> In my queeste to get only 'O's in the smokes, I have attacked the bug in AIX
> 5.2's implementation of it's localtime function. Please read and comment.
Hi,
Sorry for responding so slowly -- I had just gone on holiday when you
posted this.
> --- pp_sys.c.org2005-06-24 08:08:48.0 +0200
> +++ pp_sys.c2005-06-24 08:57:36.0 +0200
> @@ -201,6 +201,15 @@ void endservent(void);
> #undef PERL_EFF_ACCESS_W_OK
> #undef PERL_EFF_ACCESS_X_OK
>
> +/* AIX 5.2 and below use mktime for localtime, and defines the edge case
> + * for time 0x7fff to be valid only in UTC. AIX 5.3 provides localtime64
> + * available in the 32bit environment, which could warrant Configure
> + * checks in the future.
> + */
> +#ifdef _AIX
> +#define LOCALTIME_EDGECASE_BROKEN
> +#endif
> +
> /* F_OK unused: if stat() cannot find it... */
>
> #if !defined(PERL_EFF_ACCESS_R_OK) && defined(HAS_ACCESS) && defined
> (EFF_ONLY_ K) && !defined(NO_EFF_ONLY_OK)
> @@ -4510,6 +4519,42 @@ PP(pp_localtime)
> return pp_gmtime();
> }
>
> +static struct tm *my_localtime (Time_t *tp)
> +{
> +auto time_t T;
> +auto struct tm *P;
> +
> +/* No workarounds in the valid range */
> +if (!tp || *tp < 0x7fff573f || *tp >= 0x8000)
> + return (localtime (tp));
> +
> +/* This edge case is to workaround the undefined behaviour, where the
> + * TIMEZONE makes the time go beyond the defined range.
> + * gmtime (0x7fff) => 2038-01-19 03:14:07
> + * If there is a negative offset in TZ, like MET-1METDST, some broken
> + * implementations of localtime () (like AIX 5.2) barf with bogus
> + * return values:
> + * 0x7fff gmtime 2038-01-19 03:14:07
> + * 0x7fff localtime1901-12-13 21:45:51
> + * 0x7fff mylocaltime 2038-01-19 04:14:07
> + * 0x3c19137f gmtime 2001-12-13 20:45:51
> + * 0x3c19137f localtime2001-12-13 21:45:51
> + * 0x3c19137f mylocaltime 2001-12-13 21:45:51
> + * Given that legal timezones are typically between GMT-12 and GMT+12
> + * we turn back the clock 23 hours before calling the localtime
> + * function, and add those to the return value. This will never cause
> + * day wrapping problems, since the edge case is Jan *19*
> + */
> +T = *tp - 82800; /* 23 hour. allows up to GMT-23 */
> +P = localtime (&T);
> +P->tm_hour += 23;
> +if (P->tm_hour >= 24) {
> + P->tm_hour -= 24;
> + P->tm_mday++;
> +}
Well, it's not nice, but I suppose it should fix the boundary case.
However, I think you should also increment these other fields along
with tm_mday:
int tm_wday;/* Day of week (Sunday = 0) */
int tm_yday;/* Day of year (0 - 365) */
I'm not fond of this sort of struct tm manipulation. It's easy to
get wrong, and then you have just replaced a known bug by an unknown
one. Luckily, 2038-01-19 is supposed to be on a Tuesday, and we
are sufficiently far away from the boundaries of the week, month, and
year... Until someone starts using TZ=CUT-50, say :-(
Hth,
--
$_ = "Campo Weijerman [rfc822://nl.ibm.com/]" and tr-[:]/-<@>-d and print;
Perl5 Bug Summary
Perl5 Bug Summary
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
Generated at Mon Jul 18 13:00:08 2005 GMT
---
* Total Issues
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Total Issues
Open Tickets: 1470
---
New Issues
New issues that have not been responded to yet
1 - 2 weeks old
2 - 3 weeks old
36448 configuring ranlib for perl on osx with xcode 2.1
36430 Sort within a sort does not set $a, $b
3 - 4 weeks old
36347 Object destruction incomplete
4 - 5 weeks old
36333 sort CONSTANT exhibits weird behavior
36291 incorrect $! from open ">&nr" with too many open files
5 - 6 weeks old
36248 print does not respect "use encoding 'utf8'"
36235 perl + gcc-4.0.0 + solaris + gnu binutils
36229 Bizarre copy of IO
36213 Possible flaw in Safe.pm/Opcode.pm that allows access to any file
6 - 7 weeks old
36114 Segfault when use encoding with thread
36094 Wrong line number for FILEHANDLE reported by Xref (Xref.pm V1.01)
36079 use of `sexed' quotes gnot Unicode
36078 Newz() used gratuitously
36076 sv_upgrade and structure binary compatibility
36075 malloc_size/malloc_good_size
36070 Not OK: perl v5.8.7 on darwin-thread-multi-2level 8.1.0 (UNINSTALLED)
36051 LVALUE magic should know how to assign to globs
36049 Merge all the arenas
36046 Special var @- becomes arbitrarily large
7 - 8 weeks old
8 - 9 weeks old
35949 'use locale' does not enable number formatting locale
35865 tied hash bug (still present in 5.8.7-to-be), Test::More attached
9 - 10 weeks old
35427 reset coredumps pre 5.8.0
35406 Wishlist about Sys::Syslog.
10 - 11 weeks old
35180 inconsistency between PerlIO::get_layers and open/binmode
11 - 12 weeks old
35132 METABUG - AIX build issues
12 - 13 weeks old
35050 Installation Problem Perl 5.8.6 on AIX 5.2
13 - 14 weeks old
34981 binding STDIN to scalar hides fd 0 forever
14 - 15 weeks old
34905 Encode::encode and destruction of the argument
15 - 16 weeks old
34599 Perl program uses tied filehandle crashes in Komodo 3.1 debugger
16 - 17 weeks old
34524 sv_rvweaken (Scalar::Util::weaken) is inneffective on tied variables
17 - 18 weeks old
34497 hp2h unable to parse macros which have variable initialization
34496 h2ph is unable to parse do { ... } while (0) constructs in macros
34495 h2ph is unable to catenate constant strings in macros
34489 perl5db.pl noTTY=1 AutoTrace=1 cause problems
18 - 19 weeks old
19 - 20 weeks old
34349 SIGSEGV in S_regmatch
34342 @_ leaks under threads
34339 "perldoc lib" do
RE: problem building latest perl (24978) on win32
From: Dave Mitchell [mailto:[EMAIL PROTECTED] > On Fri, Jul 08, 2005 at 08:03:55PM +0100, Nick Ing-Simmons wrote: > > But if Compress::Zlib links to private "zlib" code or libz.a then there > > are two copies of code and associated symbols in the application and > > that can cause confusion at best and bugs at worst. > > Also, given that there's just been a new security vunerability in zlib, I'll post an update to Compress::Zlib this week -- zlib 1.2.3 has just been released to fix the security issue. > linking in an old private copy rather than using the OS's version, > doesn't sound like the best of policies As opposed to linking in the OS's even older shared copy :-) Ironically, one of the reasons I included a private copy of the zlib source was to allow Compress::Zlib to easily have access to a newer version of zlib than is shipped with some operating systems -- Solaris 2.8, for example, ships with zlib 1.1.4. This, of course, can be argued both ways, but with Compress::Zlib in the core, there is now a lot more scope for getting Configure to check for the presence of libz. What its does when the OS's copy of libz is older than the version included with Compress::Zlib is another question. Paul ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: Binary compatilibity of function ordering
On Mon, Jul 18, 2005 at 11:19:45AM +0100, Nicholas Clark ([EMAIL PROTECTED]) wrote: > If this is true then we can re-order functions in embed.fnc to our heart's > content in maint. Good, 'cause I already have a couple times. :-) -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
RE: Circular dependency prevents installation of Scalar-List-Utils on 5.004
OK, let's try PathTools instead of Cwd and File::Spec $ cd PathTools-3.09 $ perl5.004 Build.PL Can't locate Module/Build.pm in @INC at Build.PL line 1. BEGIN failed--compilation aborted at Build.PL line 1. Nope, PathTools -> Module::Build -> File::Spec (aka PathTools), so we have a circular dependency again. Try Makefile.PL $ cd PathTools-3.09 $ perl5.004 Makefile.PL Checking if your kit is complete... Looks good Warning: prerequisite Scalar::Util 0 not found at (eval 1) line 221. Warning: prerequisite Test 0 not found at (eval 1) line 221. Writing Makefile for Cwd And that has a dependency on the module I'm trying to build, Scalar::Util. Scalar::Util -> Module::Build -> File::Spec (aka PathTools) -> Scalar::util Paul > -Original Message- > From: H.Merijn Brand [mailto:[EMAIL PROTECTED] > Sent: 18 July 2005 14:36 > To: [EMAIL PROTECTED] > Subject: Re: Circular dependency prevents installation of Scalar-List- > Utils on 5.004 > > On Mon, 18 Jul 2005 14:30:27 +0100, "Paul Marquess" > <[EMAIL PROTECTED]> wrote: > > > I've been attempting to build Scalar-List-Utils-1.17 with perl5.004, but > > I've encountered a circular dependency in the modules that get used by > the > > build process > > Isn't this the reason why Cwd is now in Pathtools? > > > $ cd Scalar-List-Utils-1.17 > > $ perl5.004 Makefile.PL > > Can't locate File/Spec.pm in @INC at inc/Module/Install/Can.pm - > > /Users/gbarr/Library/Perl/Module/Install/Can.pm line 7. > > BEGIN failed--compilation aborted at inc/Module/Install/Can.pm - > > /Users/gbarr/Library/Perl/Module/Install/Can.pm line 7. > > Global symbol "self" requires explicit package name at > > inc/Module/Install/Makefile.pm - > > /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 80. > > Global symbol "args" requires explicit package name at > > inc/Module/Install/Makefile.pm - > > /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 86. > > syntax error at inc/Module/Install/Makefile.pm - > > /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 77, near "} > for " > > syntax error at inc/Module/Install/Makefile.pm - > > /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 95, near "}" > > The 'can_cc' method does not exist in the 'inc' path! > > Please remove the 'inc' directory and run Makefile.PL again to load it. > > > > OK, so I next tried to build File-Spec-0.90 > > > > $ cd File-Spec-0.90 > > $ perl5.004 Build.PL > > Can't locate Module/Build.pm in @INC at Build.PL line 1. > > BEGIN failed--compilation aborted at Build.PL line 1. > > > > Ok, so I now try Module-Build-0.2611 > > > > $ cd Module-Build-0.2611 > > $ perl5.004 Build.PL > > Can't locate File/Spec.pm in @INC at Build.PL line 5. > > BEGIN failed--compilation aborted at Build.PL line 5. > > > > Ugh! Circular dependency between File-Spec and Module-Build. > > > > Ahh, but both File-Spec and Module-Build ship with a Makefile.PL, so > let's > > try that route > > > > $ cd ../Module-Build-0.2611 > > $ perl5.004 Makefile.PL > > Can't locate File/Spec.pm in @INC at lib/Module/Build/Compat.pm line > 7. > > BEGIN failed--compilation aborted at lib/Module/Build/Compat.pm line > 7. > > BEGIN failed--compilation aborted at Makefile.PL line 6. > > > > And now File-Spec > > > > $ cd ../File-Spec-0.90 > > $ perl5.004 Makefile.PL > > Warning: prerequisite Cwd 2.17_02 not found at (eval 1) line 221. > > Warning: prerequisite Test 0 not found at (eval 1) line 221. > > Warning: prerequisite Test::More 0 not found at (eval 1) line 221. > > Writing Makefile for File::Spec > > > > Hmm, no circular dependency anymore, but we have a few more > dependencies. > > Looking at the first, Cwd > > > > $ cd Cwd-2.21 > > $ perl5.004 Build.PL > > Can't locate Module/Build.pm in @INC at Build.PL line 1. > > BEGIN failed--compilation aborted at Build.PL line 1. > > > > Hmm, the dependency chain is Cwd -> Module::Build -> File::Spec -> Cwd > > > > Try the Makefile.PL that ships with Cwd > > > > $ cd Cwd-2.21 > > $ perl5.004 Makefile.PL > > Warning: prerequisite File::Spec 0 not found at (eval 1) line 221. > > Warning: prerequisite Scalar::Util 0 not found at (eval 1) line 221. > > Warning: prerequisite Test::More 0 not found at (eval 1) line 221. > > Warning: prerequisite XSLoader 0 not found at (eval 1) line 221. > > Writing Makefile for Cwd > > > > And we are back in circular dependency mode again. Cwd-> File::Spec -> > Cwd > > > > Is there any way out of this "maze of twisty little passages"? > > > > Paul > > > > > > > > ___ > > How much free photo storage do you get? Store your holiday > > snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com > > > > > -- > H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) > using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11, > AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~
Circular dependency prevents installation of Scalar-List-Utils on 5.004
I've been attempting to build Scalar-List-Utils-1.17 with perl5.004, but I've encountered a circular dependency in the modules that get used by the build process $ cd Scalar-List-Utils-1.17 $ perl5.004 Makefile.PL Can't locate File/Spec.pm in @INC at inc/Module/Install/Can.pm - /Users/gbarr/Library/Perl/Module/Install/Can.pm line 7. BEGIN failed--compilation aborted at inc/Module/Install/Can.pm - /Users/gbarr/Library/Perl/Module/Install/Can.pm line 7. Global symbol "self" requires explicit package name at inc/Module/Install/Makefile.pm - /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 80. Global symbol "args" requires explicit package name at inc/Module/Install/Makefile.pm - /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 86. syntax error at inc/Module/Install/Makefile.pm - /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 77, near "} for " syntax error at inc/Module/Install/Makefile.pm - /Users/gbarr/Library/Perl/Module/Install/Makefile.pm line 95, near "}" The 'can_cc' method does not exist in the 'inc' path! Please remove the 'inc' directory and run Makefile.PL again to load it. OK, so I next tried to build File-Spec-0.90 $ cd File-Spec-0.90 $ perl5.004 Build.PL Can't locate Module/Build.pm in @INC at Build.PL line 1. BEGIN failed--compilation aborted at Build.PL line 1. Ok, so I now try Module-Build-0.2611 $ cd Module-Build-0.2611 $ perl5.004 Build.PL Can't locate File/Spec.pm in @INC at Build.PL line 5. BEGIN failed--compilation aborted at Build.PL line 5. Ugh! Circular dependency between File-Spec and Module-Build. Ahh, but both File-Spec and Module-Build ship with a Makefile.PL, so let's try that route $ cd ../Module-Build-0.2611 $ perl5.004 Makefile.PL Can't locate File/Spec.pm in @INC at lib/Module/Build/Compat.pm line 7. BEGIN failed--compilation aborted at lib/Module/Build/Compat.pm line 7. BEGIN failed--compilation aborted at Makefile.PL line 6. And now File-Spec $ cd ../File-Spec-0.90 $ perl5.004 Makefile.PL Warning: prerequisite Cwd 2.17_02 not found at (eval 1) line 221. Warning: prerequisite Test 0 not found at (eval 1) line 221. Warning: prerequisite Test::More 0 not found at (eval 1) line 221. Writing Makefile for File::Spec Hmm, no circular dependency anymore, but we have a few more dependencies. Looking at the first, Cwd $ cd Cwd-2.21 $ perl5.004 Build.PL Can't locate Module/Build.pm in @INC at Build.PL line 1. BEGIN failed--compilation aborted at Build.PL line 1. Hmm, the dependency chain is Cwd -> Module::Build -> File::Spec -> Cwd Try the Makefile.PL that ships with Cwd $ cd Cwd-2.21 $ perl5.004 Makefile.PL Warning: prerequisite File::Spec 0 not found at (eval 1) line 221. Warning: prerequisite Scalar::Util 0 not found at (eval 1) line 221. Warning: prerequisite Test::More 0 not found at (eval 1) line 221. Warning: prerequisite XSLoader 0 not found at (eval 1) line 221. Writing Makefile for Cwd And we are back in circular dependency mode again. Cwd-> File::Spec -> Cwd Is there any way out of this "maze of twisty little passages"? Paul ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: [PATCH] RE: blead: no longer supports %vd format
On 7/14/05, Robin Barker <[EMAIL PROTECTED]> wrote: > Attached patch reinstates VDf in blead perl to implement the %vd format, > which is still used in XS code and will reappear in blead for read-only > version numbers. > > I have taken the opportunity to tidy up the code for the %p hacks that > are used to proved SVf (was %_) and VDf. The format processing code > does an initial pass for %p "extensions" and then resumes the previous > processing. I have also added some comments to describe the use of %p. Thanks, applied as change #25171 to bleadperl.
RE: [perl #36586] $1 gets mysteriously unset when leaving 'for' b lock
Robin Barker wrote: >In perlre: > > The numbered match variables ($1, $2, $3, etc.) and the related > punctuation set ($+, $&, $`, $', and $^N) are all dynamically scoped > until the end of the enclosing block or until the next > successful match, whichever comes first. Thanks - my fault for not spotting that - so not a bug. -- Ed Avis <[EMAIL PROTECTED]>
Smoke [5.9.3] 25163 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25163 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 53 minutes (average 1 hour 56 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 25163 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: [PATCH] perlop: why \c\ cannot be placed just before the terminating delimiter
> SADAHIRO Tomoyuki wrote: > > diff -ur perl~/pod/perlop.pod perl/pod/perlop.pod > > --- perl~/pod/perlop.podFri Jul 15 18:33:32 2005 > > +++ perl/pod/perlop.pod Sun Jul 17 10:50:41 2005 > > @@ -1668,6 +1668,11 @@ > > the example above is not C, but rather C with no C > > modifier. So the embedded C<#> is interpreted as a literal C<#>. > > > > +Also no attention is paid to C<\c\> during this search. > > +Thus the second C<\> in C is interpleted as a part of C<\/>, > > Thanks, applied as change #25165. (assuming you meant "interpreted" > on the above line). Oh yes. Thank you for catching. SADAHIRO Tomoyuki
RE: [perl #36586] $1 gets mysteriously unset when leaving 'for' b lock
[EMAIL PROTECTED] wrote
> Somehow, although $1 was set it has been changed back to undef on
> exiting the 'for' block. I don't see anything in perlre or perlvar
> documenting this.
In perlre:
The numbered match variables ($1, $2, $3, etc.) and the related
punctuation set ($+, $&, $`, $', and $^N) are all dynamically scoped
until the end of the enclosing block or until the next successful match,
whichever comes first. (See "Compound Statements" in perlsyn.)
So this is not a bug, $1 values reverts to that for the outer block
(in your case undef) when leaving the for loop block.
Robin
-Original Message-
From: [EMAIL PROTECTED] (via RT)
To: perl5-porters@perl.org
Sent: 18/07/05 09:41
Subject: [perl #36586] $1 gets mysteriously unset when leaving 'for' block
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36586]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36586 >
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]
This test program:
my $foo = 'foo';
for ($foo) {
m!(\w+)! or die;
print "\$1 has been set to: $1\n";
}
print "\$1 is now: $1\n";
gives the output:
$1 has been set to: foo
$1 is now:
Somehow, although $1 was set it has been changed back to undef on
exiting the 'for' block. I don't see anything in perlre or perlvar
documenting this.
Surely only a regular expression match should do anything to change
the value of $1?
I have reproduced this on 5.8.4 and 5.8.7.
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.4:
Configured by ActiveState at Thu Jun 3 11:51:49 PDT 2004.
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=linux, osvers=2.2.17, archname=i686-linux-thread-multi
uname='linux gimlet 2.2.17 #1 sun jun 25 09:24:41 est 2000 i686
unknown '
config_args='-ders -Dcc=gcc -Accflags=-DNO_HASH_SEED -Dusethreads
-Duseithreads -Ud_sigsetjmp -Uinstallusrbinperl -Ulocincpth=
-Uloclibpth= -Duselargefiles -Uusemallocwrap
-Dinc_version_list=5.8.3/$archname 5.8.3 5.8.2/$archname 5.8.2
5.8.1/$archname 5.8.1 5.8.0/$archname 5.8.0 -Duseshrplib
-Dprefix=/usr/local/pkgs/ActivePerl-5.8.4.810 -Dcf_by=ActiveState
[EMAIL PROTECTED]'
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='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DNO_HASH_SEED -fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DNO_HASH_SEED -fno-strict-aliasing'
ccversion='', gccversion='2.95.2 2220 (Debian GNU/Linux)',
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='gcc', ldflags =''
libpth=/lib /usr/lib /usr/local/lib
libs=-lnsl -lndbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lposix
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -lposix
libc=/lib/libc-2.1.3.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.1.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-rpath,/usr/local/pkgs/ActivePerl-5.8.4.810/lib/5.8.4/i686-linux-thr
ead-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared'
Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
22751 Update to Test.pm 1.25
21540 Fix backward-compatibility issues in if.pm
---
@INC for perl v5.8.4:
/u/avised/lib/perl5/5.8.0
/u/avised/lib/perl5
/u/avised/lib/perl5/5.8.4
/u/avised/lib/perl5/site_perl/5.8.4
/u/avised/lib/perl5/site_perl/5.8.4/i386-linux
/u/avised/lib/perl5/site_perl/5.8.0
/u/avised/lib/perl5/site_perl
/u/avised/lib/5.8.4/i686-linux-thread-multi
/u/avised/lib/5.8.4
/u/avised/lib/site_perl/5.8.4/i686-linux-thread-multi
/u/avised/lib/site_perl/5.8.4
/u/avised/lib/site_perl/5.8.4/i386-linux
/u/avised/lib/site_perl/5.8.4/i686-linux-thread-multi
/u/avised/lib/site_perl/5.8.4
/u/avised/lib/site_perl/5.8.3/i686-linux-thread-multi
/u/avised/lib/site_perl/5.8.3
/u/avised/lib/site_perl
/u/avised/lib/site_perl/5.8.4/i686-linux-thread-multi
Re: Binary compatilibity of function ordering
On Mon, Jul 18, 2005 at 12:06:06PM +0200, Marcus Holland-Moritz wrote: > On 2005-07-06, at 10:26:31 +0100, Nicholas Clark wrote: > > > Which is the embedding configuration that needs new functions added at the > > end of embed.fnc to maintain binary compatibility? The one that this comment > > in embed.fnc refers to? > > > > : New global functions should be added at the end for binary compatibility > > : in some configurations. > > This may be a leftover from the CPerlObj days. This is my suspicion, but I"d love someone who knows to confirm this. I think that CPerlObj went away in 2001: http://public.activestate.com/cgi-bin/perlbrowse?patch=11803 If this is true then we can re-order functions in embed.fnc to our heart's content in maint. Nicholas Clark
[perl #36586] $1 gets mysteriously unset when leaving 'for' block
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36586]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36586 >
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]
This test program:
my $foo = 'foo';
for ($foo) {
m!(\w+)! or die;
print "\$1 has been set to: $1\n";
}
print "\$1 is now: $1\n";
gives the output:
$1 has been set to: foo
$1 is now:
Somehow, although $1 was set it has been changed back to undef on
exiting the 'for' block. I don't see anything in perlre or perlvar
documenting this.
Surely only a regular expression match should do anything to change
the value of $1?
I have reproduced this on 5.8.4 and 5.8.7.
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.4:
Configured by ActiveState at Thu Jun 3 11:51:49 PDT 2004.
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=linux, osvers=2.2.17, archname=i686-linux-thread-multi
uname='linux gimlet 2.2.17 #1 sun jun 25 09:24:41 est 2000 i686 unknown '
config_args='-ders -Dcc=gcc -Accflags=-DNO_HASH_SEED -Dusethreads
-Duseithreads -Ud_sigsetjmp -Uinstallusrbinperl -Ulocincpth= -Uloclibpth=
-Duselargefiles -Uusemallocwrap -Dinc_version_list=5.8.3/$archname 5.8.3
5.8.2/$archname 5.8.2 5.8.1/$archname 5.8.1 5.8.0/$archname 5.8.0 -Duseshrplib
-Dprefix=/usr/local/pkgs/ActivePerl-5.8.4.810 -Dcf_by=ActiveState [EMAIL
PROTECTED]'
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='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DNO_HASH_SEED -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DNO_HASH_SEED
-fno-strict-aliasing'
ccversion='', gccversion='2.95.2 2220 (Debian GNU/Linux)',
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='gcc', ldflags =''
libpth=/lib /usr/lib /usr/local/lib
libs=-lnsl -lndbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lposix
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -lposix
libc=/lib/libc-2.1.3.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.1.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-rpath,/usr/local/pkgs/ActivePerl-5.8.4.810/lib/5.8.4/i686-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared'
Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
22751 Update to Test.pm 1.25
21540 Fix backward-compatibility issues in if.pm
---
@INC for perl v5.8.4:
/u/avised/lib/perl5/5.8.0
/u/avised/lib/perl5
/u/avised/lib/perl5/5.8.4
/u/avised/lib/perl5/site_perl/5.8.4
/u/avised/lib/perl5/site_perl/5.8.4/i386-linux
/u/avised/lib/perl5/site_perl/5.8.0
/u/avised/lib/perl5/site_perl
/u/avised/lib/5.8.4/i686-linux-thread-multi
/u/avised/lib/5.8.4
/u/avised/lib/site_perl/5.8.4/i686-linux-thread-multi
/u/avised/lib/site_perl/5.8.4
/u/avised/lib/site_perl/5.8.4/i386-linux
/u/avised/lib/site_perl/5.8.4/i686-linux-thread-multi
/u/avised/lib/site_perl/5.8.4
/u/avised/lib/site_perl/5.8.3/i686-linux-thread-multi
/u/avised/lib/site_perl/5.8.3
/u/avised/lib/site_perl
/u/avised/lib/site_perl/5.8.4/i686-linux-thread-multi
/usr/local/pkgs/ActivePerl-5.8.4.810/lib/site_perl/5.8.4/i686-linux-thread-multi
/usr/local/pkgs/ActivePerl-5.8.4.810/lib/site_perl/5.8.4
/prod/datatech/inferno/bin/scripts
/usr/local/pkgs/ActivePerl-5.8.4.810/lib/5.8.4/i686-linux-thread-multi
/usr/local/pkgs/ActivePerl-5.8.4.810/lib/5.8.4
/usr/local/pkgs/ActivePerl-5.8.4.810/lib/site_perl/5.8.4/i686-linux-thread-multi
/usr/local/pkgs/ActivePerl-5.8.4.810/lib/site_perl/5.8.4
/usr/local/pkgs/ActivePerl-5.8.4.810/lib/site_perl
.
---
Environment for perl v5.8.4:
HOME=/u/avised
LANG=en_US.UTF-8
LANGUAGE (unset)
LANGVAR=en_US.UTF-8
LD_LIBRARY_PATH=/u/avised/lib:/usr/local/lib:/usr/local/oracle/lib:/usr/local/deshaw/lib:/usr/local/pkgs/systems/lib:/usr/local/X11R6/lib
Re: Binary compatilibity of function ordering
On 2005-07-06, at 10:26:31 +0100, Nicholas Clark wrote: > Which is the embedding configuration that needs new functions added at the > end of embed.fnc to maintain binary compatibility? The one that this comment > in embed.fnc refers to? > > : New global functions should be added at the end for binary compatibility > : in some configurations. This may be a leftover from the CPerlObj days. Marcus -- Lieberman's Law: Everybody lies, but it doesn't matter since nobody listens.
Re: [perl #36526] Incorrect (X)HTML generated by Pod::Html
Steve Hay wrote: > Removing those line breaks is definitely an improvement, but the patch > also inserts extra space into style lists - e.g. see the old and > new examples (from the Benchmark manpage) attached. > > Looks fine to me, but before I commit it is anyone particularly wedded > to the more compact old look? I think it's ok, fixing generated HTML is more important than being rendering-compatible.
Re: [perl #36526] Incorrect (X)HTML generated by Pod::Html
Earl Hood (via RT) wrote: >Pod::Html generated invalid markup for lists. For example, >a numbered listed turns out as: > > > >...text here... > >... > >Causing lists to be rendered like: > > 1. >... text here ... > > 2. >... text here ... > >Or for unordered lists: > > * >... text here ... > > * >... text here ... > >Notice the annoying line break after each bullet. > Removing those line breaks is definitely an improvement, but the patch also inserts extra space into style lists - e.g. see the old and new examples (from the Benchmark manpage) attached. Looks fine to me, but before I commit it is anyone particularly wedded to the more compact old look? Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [perl #27028] /$/ not honouring /m in some cases
On 7/14/05, Rick Delaney <[EMAIL PROTECTED]> wrote: > Here's one way. Line 614 of t/op/re_tests fits the bill. I'm a little > disappointed that this patch didn't shake out any more bugs. I guess > we're getting close to a bug-free regex engine. ;-) Thanks, almost a thousand tests added as change #25166.
Re: [PATCH] perlop: why \c\ cannot be placed just before the terminating delimiter
SADAHIRO Tomoyuki wrote: > diff -ur perl~/pod/perlop.pod perl/pod/perlop.pod > --- perl~/pod/perlop.pod Fri Jul 15 18:33:32 2005 > +++ perl/pod/perlop.pod Sun Jul 17 10:50:41 2005 > @@ -1668,6 +1668,11 @@ > the example above is not C, but rather C with no C > modifier. So the embedded C<#> is interpreted as a literal C<#>. > > +Also no attention is paid to C<\c\> during this search. > +Thus the second C<\> in C is interpleted as a part of C<\/>, Thanks, applied as change #25165. (assuming you meant "interpreted" on the above line). > +and the following C is not recognized as delimiter. > +Instead, use C<\034> or C<\x1c> at the end of quoted constructs.
Re: Why does our() cross packages? (PATCH)
Michael G Schwern wrote: >On Fri, Jul 15, 2005 at 03:59:13PM -0500, David Nicol wrote: > > >>How does the attached patch grab you? >> >> > >Piecing it together, these are the leading paragraphs: > Thanks. Applied as change 25164 (with the other tweaks suggested incorporated). Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [PATCH] Configure grammar nit
On Sun, Jul 17, 2005 at 02:57:47PM +0300, [EMAIL PROTECTED] wrote: > >Yes, but "right" is an adjective, so you shouldn't be using it with a verb > Huh? In what kind of English? > > http://dictionary.reference.com/search?q=right > > says, among other things, see esp. 8. > > adv. > >1. Toward or on the right. >2. In a straight line; directly: went right to school. >3. In the proper or desired manner; well: The jacket doesn't fit right. >4. Exactly; just: The accident happened right over there. >5. Immediately: called me right after dinner. >6. Completely; quite: The icy wind blew right through me. >7. According to law, morality, or justice. >8. Accurately; correctly: answered the question right. >9. Chiefly Southern U.S. Considerably; very: They have a right nice > place. > 10. Used as an intensive: kept right on going. > 11. Used in titles: The Right Reverend Jane Smith. > > > >You did ask :-) > You did answer :-) Or is it a joke I can't get? Looks like US grammar rules differ. It's certainly directly contrary to what I was taught. Nicholas Clark
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Mon, Jul 18, 2005 at 12:31:36AM +0200, Gerrit P. Haase wrote: > >Maybe a cygwin problem, I'll fetch a snapshot. > > With the latest snapshot I see the same behaviour. > > Are there other modules involved besides MM and TH? MakeMaker is not involved, just Test::Harness. All the action is in or called from Test::Harness::Straps->analyze_file. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
Michael G Schwern wrote:
On Mon, Jul 18, 2005 at 12:27:31AM +0200, Gerrit P. Haase wrote:
perl -MTest::Harness -Iblib/lib -Iblib/arch -wle '$Test::Harness::Debug =
1; $Test::Harness::Verbose = 1; runtests @ARGV' t/*.t
The lines we're looking for are "# PERL5LIB=..." from THS->analyze_file()
telling us how TH is setting @INC.
t/test0# Running: /usr/bin/perl -w t/test0.t
# PERL5LIB=blib/lib:blib/arch
1..1
# Running under perl version 5.008007 for cygwin
# Current time local: Mon Jul 18 00:14:08 2005
# Current time GMT: Sun Jul 17 22:14:08 2005
# Using Test.pm version 1.25
ok 1
ok
t/test1# Running: /usr/bin/perl -w t/test1.t
# PERL5LIB=
At this point I'd suspect there's something broken about %ENV. Try replacing
this in THS->analyze_file:
local $ENV{PERL5LIB} = $self->_INC2PERL5LIB;
if ( $Test::Harness::Debug ) {
local $^W=0; # ignore undef warnings
print "# PERL5LIB=$ENV{PERL5LIB}\n";
}
with this:
my $libs = $self->_INC2PERL5LIB;
local $ENV{PERL5LIB} = $libs;
if ( $Test::Harness::Debug ) {
local $^W=0; # ignore undef warnings
print STDERR "# PERL5LIB=$ENV{PERL5LIB}\n";
print STDERR "# libs=$libs\n";
}
to determine if _INC2PERL5LIB() is acting properly.
$ perl -MTest::Harness -Iblib/lib -Iblib/arch -wle
'$Test::Harness::Debug = 1; $Test::Harness::Verbose = 1; runtests
@ARGV' t/*.t
t/test0# Running: /usr/bin/perl -w t/test0.t
# PERL5LIB=blib/lib:blib/arch
# libs=blib/lib:blib/arch
1..1
# Running under perl version 5.008007 for cygwin
# Current time local: Mon Jul 18 00:59:23 2005
# Current time GMT: Sun Jul 17 22:59:23 2005
# Using Test.pm version 1.25
ok 1
ok
t/test1# Running: /usr/bin/perl -w t/test1.t
# PERL5LIB=
# libs=
Can't locate TestModule.pm in @INC (@INC contains:
/usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at
t/test1.t line 2.
BEGIN failed--compilation aborted at t/test1.t line 2.
dubious
Test returned status 2 (wstat 512, 0x200)
t/test2# Running: /usr/bin/perl -w t/test2.t
# PERL5LIB=blib/lib:blib/arch
# libs=blib/lib:blib/arch
1..1
# Running under perl version 5.008007 for cygwin
# Current time local: Mon Jul 18 00:59:24 2005
# Current time GMT: Sun Jul 17 22:59:24 2005
# Using Test.pm version 1.25
ok 1
ok
t/test3# Running: /usr/bin/perl -w t/test3.t
# PERL5LIB=
# libs=
Can't locate TestModule.pm in @INC (@INC contains:
/usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at
t/test3.t line 2.
BEGIN failed--compilation aborted at t/test3.t line 2.
dubious
Test returned status 2 (wstat 512, 0x200)
t/test4# Running: /usr/bin/perl -w t/test4.t
# PERL5LIB=blib/lib:blib/arch
# libs=blib/lib:blib/arch
1..1
# Running under perl version 5.008007 for cygwin
# Current time local: Mon Jul 18 00:59:25 2005
# Current time GMT: Sun Jul 17 22:59:25 2005
# Using Test.pm version 1.25
ok 1
ok
t/test5# Running: /usr/bin/perl -w t/test5.t
# PERL5LIB=
# libs=
Can't locate TestModule.pm in @INC (@INC contains:
/usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at
t/test5.t line 2.
BEGIN failed--compilation aborted at t/test5.t line 2.
dubious
Test returned status 2 (wstat 512, 0x200)
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/test1.t 2 512?? ?? % ??
t/test3.t 2 512?? ?? % ??
t/test5.t 2 512?? ?? % ??
Failed 3/6 test scripts, 50.00% okay. 0/3 subtests failed, 100.00% okay.
--
=^..^=
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
Michael G Schwern wrote: On Sun, Jul 17, 2005 at 11:43:39PM +0200, Gerrit P. Haase wrote: Nope, Teat::Harness now at version 2.52: $ make test /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t Ok, see if MakeMaker has anything to do with this by running: perl -MTest::Harness -Iblib/lib -Iblib/arch -wle 'runtests @ARGV' t/*.t If it still fails then we know MakeMaker is not involved. I don't think it is. $ perl -MTest::Harness -Iblib/lib -Iblib/arch -wle 'runtests @ARGV' [...] Failed Test Stat Wstat Total Fail Failed List of Failed - t/test1.t 2 512?? ?? % ?? t/test3.t 2 512?? ?? % ?? t/test5.t 2 512?? ?? % ?? Failed 3/6 test scripts, 50.00% okay. 0/3 subtests failed, 100.00% okay. Then try: perl -MTest::Harness -Iblib/lib -Iblib/arch -wle '$Test::Harness::Debug = 1; $Test::Harness::Verbose = 1; runtests @ARGV' t/*.t The lines we're looking for are "# PERL5LIB=..." from THS->analyze_file() telling us how TH is setting @INC. t/test0# Running: /usr/bin/perl -w t/test0.t # PERL5LIB=blib/lib:blib/arch 1..1 # Running under perl version 5.008007 for cygwin # Current time local: Mon Jul 18 00:14:08 2005 # Current time GMT: Sun Jul 17 22:14:08 2005 # Using Test.pm version 1.25 ok 1 ok t/test1# Running: /usr/bin/perl -w t/test1.t # PERL5LIB= Can't locate TestModule.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/l ib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5 /vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at t/test1.t line 2. BEGIN failed--compilation aborted at t/test1.t line 2. dubious Test returned status 2 (wstat 512, 0x200) t/test2# Running: /usr/bin/perl -w t/test2.t # PERL5LIB=blib/lib:blib/arch 1..1 # Running under perl version 5.008007 for cygwin # Current time local: Mon Jul 18 00:14:09 2005 # Current time GMT: Sun Jul 17 22:14:09 2005 # Using Test.pm version 1.25 ok 1 ok t/test3# Running: /usr/bin/perl -w t/test3.t # PERL5LIB= Can't locate TestModule.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/l ib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5 /vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at t/test3.t line 2. BEGIN failed--compilation aborted at t/test3.t line 2. dubious Test returned status 2 (wstat 512, 0x200) t/test4# Running: /usr/bin/perl -w t/test4.t # PERL5LIB=blib/lib:blib/arch 1..1 # Running under perl version 5.008007 for cygwin # Current time local: Mon Jul 18 00:14:10 2005 # Current time GMT: Sun Jul 17 22:14:10 2005 # Using Test.pm version 1.25 ok 1 ok t/test5# Running: /usr/bin/perl -w t/test5.t # PERL5LIB= Can't locate TestModule.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/l ib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5 /vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at t/test5.t line 2. BEGIN failed--compilation aborted at t/test5.t line 2. dubious Test returned status 2 (wstat 512, 0x200) Failed Test Stat Wstat Total Fail Failed List of Failed - t/test1.t 2 512?? ?? % ?? t/test3.t 2 512?? ?? % ?? t/test5.t 2 512?? ?? % ?? Failed 3/6 test scripts, 50.00% okay. 0/3 subtests failed, 100.00% okay. You'll probably also want to look at the output of THS->_command_line(). Unfortunately there's not a $Debug print for that so you should put one in. $ perl -MTest::Harness -Iblib/lib -Iblib/arch -wle '$Test::Harness::Debug = 1; $Test::Harness::Verbose = 1; runtests @ARGV' t/*.t t/test0# _command_line: /usr/bin/perl -w t/test0.t # Running: /usr/bin/perl -w t/test0.t # PERL5LIB=blib/lib:blib/arch # _command_line: /usr/bin/perl -w t/test0.t 1..1 # Running under perl version 5.008007 for cygwin # Current time local: Mon Jul 18 00:26:34 2005 # Current time GMT: Sun Jul 17 22:26:34 2005 # Using Test.pm version 1.25 ok 1 ok t/test1# _command_line: /usr/bin/perl -w t/test1.t # Running: /usr/bin/perl -w t/test1.t # PERL5LIB= # _command_line: /usr/bin/perl -w t/test1.t Can't locate TestModule.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
Gerrit P. Haase wrote: Maybe a cygwin problem, I'll fetch a snapshot. With the latest snapshot I see the same behaviour. Are there other modules involved besides MM and TH? Gerrit -- =^..^=
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
I have installed M/MS/MSCHWERN/ExtUtils-MakeMaker-6.30.tar.gz now, still the same, every second test fails because blib/lib isn't present in @INC (every second test). Gerrit -- =^..^=
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
Michael G Schwern wrote: On Sun, Jul 17, 2005 at 10:16:40PM +0200, Gerrit P. Haase wrote: I'm going to guess somethign wacky is going on inside Test::Harness. What version is being used? The dafault Test::Harness which is included with perl-5.8.7: $ perl -e 'use Test::Harness; print "$Test::Harness::VERSION\n";' 2.48 Try upgrading TH and see if that fixes it. Nope, Teat::Harness now at version 2.52: $ make test /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/test0ok t/test1Can't locate TestModule.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at t/test1.t line 2. BEGIN failed--compilation aborted at t/test1.t line 2. t/test1dubious Test returned status 2 (wstat 512, 0x200) t/test2ok t/test3Can't locate TestModule.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at t/test3.t line 2. BEGIN failed--compilation aborted at t/test3.t line 2. t/test3dubious Test returned status 2 (wstat 512, 0x200) t/test4ok t/test5Can't locate TestModule.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at t/test5.t line 2. BEGIN failed--compilation aborted at t/test5.t line 2. t/test5dubious Test returned status 2 (wstat 512, 0x200) Failed Test Stat Wstat Total Fail Failed List of Failed t/test1.t 2 512?? ?? % ?? t/test3.t 2 512?? ?? % ?? t/test5.t 2 512?? ?? % ?? Failed 3/6 test scripts, 50.00% okay. 0/3 subtests failed, 100.00% okay. make: *** [test_dynamic] Error 14 @INC path in MM.pm is still correct: /home/gerrit/perltemp/TestModule_broken/blib/lib /home/gerrit/perltemp/TestModule_broken/blib/arch /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 . Maybe a cygwin problem, I'll fetch a snapshot. Gerrit -- =^..^=
Re: [perl #23666] Core dump on big regex
On 18/07/2005, at 2:05 AM, Michael G Schwern via RT wrote:
[EMAIL PROTECTED] - Sat Aug 30 14:33:01 2003]:
perl -wle '("1"x5683)=~ /^(11+)\1+$/'
works ok
perl -wle '("1"x 9973)=~ /^(11+)\1+$/'
Segmentation fault (core dumped)
ulimit -a
...
stack size (kbytes) 1048576
...
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 '("1"x 19973)=~ /^(11+)\1+$/'
Segmentation fault
I don't have a newer Perl on Linux to try out.
Neither do I. However, I'll jump in anyway:
Yet another case to be linked to the #24274 deep-regex-recursion-
causes-stack-overflow metabug:
$ perl -v
This is perl, v5.8.6 built for darwin-thread-multi-2level
...
$ ulimit -a
core file size(blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files(-n) 256
pipe size (512 bytes, -p) 1
stack size(kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes(-u) 100
virtual memory(kbytes, -v) unlimited
$ ulimit -s 2048
$ perl -wle '("1"x5683)=~ /^(11+)\1+$/'
$ ulimit -s 1024
$ perl -wle '("1"x5683)=~ /^(11+)\1+$/'
Segmentation fault
From the crash log:
Host Name: Tullamore
Date/Time: 2005-07-18 09:45:49.115 +0200
OS Version: 10.4.2 (Build 8C46)
Report Version: 3
Command: perl
Path:/sw/bin/perl
Parent: bash [22803]
Version: ??? (???)
PID:22826
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbfe0
Thread 0 Crashed:
0 libSystem.B.dylib 0x90005e28 szone_size + 28
1 libSystem.B.dylib 0x9001793c realloc + 1500
2 perl 0x3bec Perl_safesysrealloc + 120 (crt.c:
300)
3 perl 0x00089020 Perl_savestack_grow_cnt + 80
(crt.c:300)
4 perl 0x000b7664 S_regcppush + 92 (crt.c:300)
5 perl 0x000bdcc4 S_regmatch + 8076 (crt.c:300)
6 perl 0x000bdce0 S_regmatch + 8104 (crt.c:300)
...
507 perl 0x000bdce0 S_regmatch + 8104 (crt.c:300)
508 perl 0x000bdce0 S_regmatch + 8104 (crt.c:300)
Thread 0 crashed with PPC Thread State 64:
srr0: 0x90005e28 srr1:
0x1000d030vrsave: 0x
cr: 0x48042224 xer: 0x2000 lr:
0x90005e1c ctr: 0x90005e0c
r0: 0x9001793c r1: 0xbff00040 r2:
0xa0007374 r3: 0x0180
r4: 0x00205000 r5: 0x0054 r6:
0x r7: 0x0031
r8: 0x0031 r9: 0x0011 r10:
0x00305e30 r11: 0x000e2828
r12: 0x90005e0c r13: 0x r14:
0x r15: 0x
r16: 0x r17: 0x r18:
0x r19: 0x
r20: 0x0002 r21: 0x r22:
0x00305be0 r23: 0x000109a4
r24: 0x00205000 r25: 0x0180e222 r26:
0x0180e224 r27: 0x4263
r28: 0x0180 r29: 0x0180 r30:
0x00205000 r31: 0x90005e1c
Binary Images Description:
0x1000 -0xd9fff perl /sw/bin/perl
0x8fe0 - 0x8fe51fff dyld 43.1/usr/lib/dyld
0x9000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/
libmathCommon.A.dylib
Behaviour is the same with [EMAIL PROTECTED]
--
Dominic Dunlop
