opcode sequence.
Hi,
Here's a test on perl-5.8.6 run on z/OS :
$a = '0178';
$b = '00FF';
$a1 = pack(U0U*, hex $a);
$b1 = pack(U0U*, map { hex } split , $b);
if (:$b1: =~ /:[$a1]:/i)
print ok;
The test runs through the opcodes OP_REGCOMP, OP_MATCH and then gets into the
opcode OP_COND_EXPR.
Now, if I change $a = '212B' and $b = '00E5'
the test runs through the opcodes OP_REGCOMP, OP_MATCH and then gets into
OP_AND (and not OP_COND_EXPR).
why is this so ?
Thanks,
Rajarshi.
-
Start your day with Yahoo! - make it your home page
Re: [EMAIL PROTECTED] fixes to const fixes + Case Preserved start
John E. Malmberg wrote: I found some cases where the wrong pointer was being used as a result of the previous const fixes. Also added in fixes to better handle EFS file specifications and the underpinnings for the using the Case Sensitive and the Case Preserved mode of the VMS file system. Thanks, applied as change #25306.
Re: RFC - eliminate discrete arenaroots
Jim Cromie wrote:
attached is an almost-there patch which:
this patch, on top of previous, gets it there.
The problem was my earlier use of Zero() in perl_clone().
(sizeof Foo is not a type, and not a compiler error either)
On thread no-thread, all but 1 tests pass.
t/op/sprintf..FAILED at test 239
Ive been seeing this before..
After fixing the above, I did some more stuff,
theres still more cleanup to do.
diff -ruN -X exclude-diffs array-arena/.patches array-arena-bld/.patches
--- array-arena/.patches2005-08-18 16:26:25.0 -0600
+++ array-arena-bld/.patches1969-12-31 17:00:00.0 -0700
@@ -1 +0,0 @@
-diff.array-arena-bld.pub2
diff -ruN -X exclude-diffs array-arena/perlapi.h array-arena-bld/perlapi.h
--- array-arena/perlapi.h 2005-08-18 16:26:25.0 -0600
+++ array-arena-bld/perlapi.h 2005-08-18 23:52:16.0 -0600
@@ -670,50 +670,6 @@
#define PL_warnhook(*Perl_Iwarnhook_ptr(aTHX))
#undef PL_widesyscalls
#define PL_widesyscalls(*Perl_Iwidesyscalls_ptr(aTHX))
-#undef PL_xnv_arenaroot
-#define PL_xnv_arenaroot (*Perl_Ixnv_arenaroot_ptr(aTHX))
-#undef PL_xnv_root
-#define PL_xnv_root(*Perl_Ixnv_root_ptr(aTHX))
-#undef PL_xpv_arenaroot
-#define PL_xpv_arenaroot (*Perl_Ixpv_arenaroot_ptr(aTHX))
-#undef PL_xpv_root
-#define PL_xpv_root(*Perl_Ixpv_root_ptr(aTHX))
-#undef PL_xpvav_arenaroot
-#define PL_xpvav_arenaroot (*Perl_Ixpvav_arenaroot_ptr(aTHX))
-#undef PL_xpvav_root
-#define PL_xpvav_root (*Perl_Ixpvav_root_ptr(aTHX))
-#undef PL_xpvbm_arenaroot
-#define PL_xpvbm_arenaroot (*Perl_Ixpvbm_arenaroot_ptr(aTHX))
-#undef PL_xpvbm_root
-#define PL_xpvbm_root (*Perl_Ixpvbm_root_ptr(aTHX))
-#undef PL_xpvcv_arenaroot
-#define PL_xpvcv_arenaroot (*Perl_Ixpvcv_arenaroot_ptr(aTHX))
-#undef PL_xpvcv_root
-#define PL_xpvcv_root (*Perl_Ixpvcv_root_ptr(aTHX))
-#undef PL_xpvgv_arenaroot
-#define PL_xpvgv_arenaroot (*Perl_Ixpvgv_arenaroot_ptr(aTHX))
-#undef PL_xpvgv_root
-#define PL_xpvgv_root (*Perl_Ixpvgv_root_ptr(aTHX))
-#undef PL_xpvhv_arenaroot
-#define PL_xpvhv_arenaroot (*Perl_Ixpvhv_arenaroot_ptr(aTHX))
-#undef PL_xpvhv_root
-#define PL_xpvhv_root (*Perl_Ixpvhv_root_ptr(aTHX))
-#undef PL_xpviv_arenaroot
-#define PL_xpviv_arenaroot (*Perl_Ixpviv_arenaroot_ptr(aTHX))
-#undef PL_xpviv_root
-#define PL_xpviv_root (*Perl_Ixpviv_root_ptr(aTHX))
-#undef PL_xpvlv_arenaroot
-#define PL_xpvlv_arenaroot (*Perl_Ixpvlv_arenaroot_ptr(aTHX))
-#undef PL_xpvlv_root
-#define PL_xpvlv_root (*Perl_Ixpvlv_root_ptr(aTHX))
-#undef PL_xpvmg_arenaroot
-#define PL_xpvmg_arenaroot (*Perl_Ixpvmg_arenaroot_ptr(aTHX))
-#undef PL_xpvmg_root
-#define PL_xpvmg_root (*Perl_Ixpvmg_root_ptr(aTHX))
-#undef PL_xpvnv_arenaroot
-#define PL_xpvnv_arenaroot (*Perl_Ixpvnv_arenaroot_ptr(aTHX))
-#undef PL_xpvnv_root
-#define PL_xpvnv_root (*Perl_Ixpvnv_root_ptr(aTHX))
#undef PL_yycharp
#define PL_yycharp (*Perl_Iyycharp_ptr(aTHX))
#undef PL_yylvalp
diff -ruN -X exclude-diffs array-arena/sv.c array-arena-bld/sv.c
--- array-arena/sv.c2005-08-18 16:26:25.0 -0600
+++ array-arena-bld/sv.c2005-08-18 23:52:15.0 -0600
@@ -1151,25 +1151,48 @@
} STMT_END
/* map sv-type to its allocated size
- Not used yet - it is wrong on allocated items
- */
+ Note that 1st 4 sv-types have no bodies,
+ *_allocated bodies are smaller cuz they have unused slots.
+*/
+
static int sizeof_body_by_svtype[] = {
-0, /* SVt_NULLs have no body */
-0, /* SVt_IVs have no body */
-0, //sizeof(XNV), /* 2 */
-0, /* SVt_RVs have no body */
-sizeof(XPV), /* 4 allocated */
-sizeof(XPVIV), /* 5 allocated */
-sizeof(XPVNV), /* 6 */
-sizeof(XPVMG), /* 7 */
-sizeof(XPVBM), /* 8 */
-sizeof(XPVGV), /* 9 */
-sizeof(XPVLV), /* 10 */
-sizeof(XPVAV), /* 11 allocated */
-sizeof(XPVHV), /* 12 allocated */
-sizeof(XPVCV), /* 13 */
-sizeof(XPVFM), /* 14 */
-sizeof(XPVIO)/* 15 */
+0, /* SVt_NULLs, SVt_IVs, SVt_NVs, SVt_RVs have no body */
+0,
+0,
+0,
+sizeof(xpv_allocated),
+sizeof(xpviv_allocated),
+sizeof(XPVNV),
+sizeof(XPVMG),
+sizeof(XPVBM),
+sizeof(XPVGV),
+sizeof(XPVLV),
+sizeof(xpvav_allocated),
+sizeof(xpvhv_allocated),
+sizeof(XPVCV),
+sizeof(XPVFM),
+sizeof(XPVIO)
+};
+
+/* Map (by type) an address offset for *_allocated bodies, */
+
+static int offset_by_svtype[] = {
+0,
+0,
+0,
+0,
+STRUCT_OFFSET(xpv_allocated, xpv_cur) - STRUCT_OFFSET(XPV, xpv_cur),
+STRUCT_OFFSET(xpviv_allocated, xpv_cur) - STRUCT_OFFSET(XPVIV, xpv_cur),
+0,
+0,
+0,
+0,
+0,
+
Re: opcode sequence.
On Thu, Aug 18, 2005 at 11:19:16PM -0700, rajarshi das wrote:
Hi,
Here's a test on perl-5.8.6 run on z/OS :
$a = '0178';
$b = '00FF';
$a1 = pack(U0U*, hex $a);
$b1 = pack(U0U*, map { hex } split , $b);
if (:$b1: =~ /:[$a1]:/i)
print ok;
The test runs through the opcodes OP_REGCOMP, OP_MATCH and then gets
into the opcode OP_COND_EXPR.
Well, the test above should in fact give a syntax error, since that's not
a valid if syntax.
--
Britain, Britain, Britain! Discovered by Sir Henry Britain in
sixteen-oh-ten. Sold to Germany a year later for a pfennig and the promise
of a kiss. Destroyed in eighteen thirty-fourty two, and rebuilt a week
later by a man. This we know. Hello. But what of the people of Britain?
Who they? What do? And why? -- Little Britain
Re: opcode sequence.
Dave Mitchell [EMAIL PROTECTED] wrote:
On Thu, Aug 18, 2005 at 11:19:16PM -0700, rajarshi das wrote:
Hi,
Here's a test on perl-5.8.6 run on z/OS :
$a = '0178';
$b = '00FF';
$a1 = pack(U0U*, hex $a);
$b1 = pack(U0U*, map { hex } split , $b);
if (:$b1: =~ /:[$a1]:/i) {
print ok;
}
The test runs through the opcodes OP_REGCOMP, OP_MATCH and then gets
into the opcode OP_COND_EXPR.
Well, the test above should in fact give a syntax error, since that's not
a valid if syntax.
I have included the braces if that is what you meant.
Rajarshi.
--
Britain, Britain, Britain! Discovered by Sir Henry Britain in
sixteen-oh-ten. Sold to Germany a year later for a pfennig and the promise
of a kiss. Destroyed in eighteen thirty-fourty two, and rebuilt a week
later by a man. This we know. Hello. But what of the people of Britain?
Who they? What do? And why? -- Little Britain
-
Start your day with Yahoo! - make it your home page
Re: opcode sequence.
On Fri, Aug 19, 2005 at 12:51:09AM -0700, rajarshi das wrote:
Dave Mitchell [EMAIL PROTECTED] wrote:
On Thu, Aug 18, 2005 at 11:19:16PM -0700, rajarshi das wrote:
Hi,
Here's a test on perl-5.8.6 run on z/OS :
$a = '0178';
$b = '00FF';
$a1 = pack(U0U*, hex $a);
$b1 = pack(U0U*, map { hex } split , $b);
if (:$b1: =~ /:[$a1]:/i) {
print ok;
}
The test runs through the opcodes OP_REGCOMP, OP_MATCH and then gets
into the opcode OP_COND_EXPR.
Well, the test above should in fact give a syntax error, since that's not
a valid if syntax.
I have included the braces if that is what you meant.
cond_expr would be there if there were an else clause.
Re: opcode sequence.
Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote:
On Fri, Aug 19, 2005 at 12:51:09AM -0700, rajarshi das wrote:
Dave Mitchell wrote:
On Thu, Aug 18, 2005 at 11:19:16PM -0700, rajarshi das wrote:
Hi,
Here's a test on perl-5.8.6 run on z/OS :
$a = '0178';
$b = '00FF';
$a1 = pack(U0U*, hex $a);
$b1 = pack(U0U*, map { hex } split , $b);
if (:$b1: =~ /:[$a1]:/i) {
print ok;
}
The test runs through the opcodes OP_REGCOMP, OP_MATCH and then gets
into the opcode OP_COND_EXPR.
Well, the test above should in fact give a syntax error, since that's not
a valid if syntax.
I have included the braces if that is what you meant.
cond_expr would be there if there were an else clause.
But the test doesnot contain an else clause. What I have indicated above is
exactly what I run.
Rajarshi.
-
Yahoo! Mail for Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
Re: RFC - eliminate discrete arenaroots
-BEGIN PGP SIGNED MESSAGE-
Moin,
Jim Cromie [EMAIL PROTECTED] wrote:
attached is an almost-there patch which:
replaces most arena-root pointers with an array of them
replaces same root pointers with array.
simplifies several macros using them.
the line-count doesnt shrink much, but it simplifies source code, and
shrinks object code:
I didn't understand this comparisation fully. Are this bytes used by the
functions?
Anyway, this work sounds good. Just one small detail:
+
+for (i=0; i17; i++) {
+ S_free_arena(aTHX_ (void**) PL_body_arenaroots[i]);
+ PL_body_arenaroots[i] = 0;
+ PL_body_roots[i] = 0;
+}
The 17 should be defined somewhere. It might change someday :)
+ Note that 1st 4 sv-types have no bodies,
+ *_allocated bodies are smaller cuz they have unused slots.
+*/
I do not like the abbrevitation cuz. I sometimes use w/ and w/o, but
the former is already borderline for me. I think you have the time to
spell comments out. Otherwise we will see comments like this one next:
/* 4 u we r ! d0ing teh all0cat'n */
:-D
Best wishes,
Tels
- --
Signed on Fri Aug 19 11:20:41 2005 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
Let's say there are a thousand. But there are 284 million people in
this country. You can't have public policy that is aimed at 100,000
people when the other multi-multi-millions are also involved. You can't
do it that way. - Jack Valenty in http://tinyurl.com/2y65n
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQwWl1ncLPEOTuEwVAQGjPgf+N8yWGLZe0/HsSufknUxOT6Q8Zet1EQ7g
omUiEzHnDIm7uhsdIh5lxfnEs+sWJC1dzVK08KCati1bFhY3b/NkLc1tm75kZ84O
Ms5qyAo9udRzFGywGhv+X6cQtbq9/VlTIDQzPf1A7VO75F1R3hCLMD1EXNdLnZP1
GRRK44b5WjRBNuMNhm8/8QsqUP647AkZOGfpmvfYARRwQcbUsweGqlOKpHk21Rbc
Un+SeiIH/VTUUUy7A5zPYwO4mcQpbHUxhsavSYZN1x8CMWLSzXITZCoCuTmILXZS
sdlAQ6zIF/scBUmr52rI9ARBgr1lC43fKujSOtk+Ob7ExEgILXy7hw==
=y8X9
-END PGP SIGNATURE-
[perl #36949] Small error in Encode manpage
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36949] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36949 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] The Encode manpage as of perl 5.8.6 reads: find_encoding(UTF-8)-name # is ’utf-8-strict’ find_encoding(utf-8)-name # ditto. names are case insensitive find_encoding(utf8)-name # ditto. _ are treated as - find_encoding(UTF8)-name # is ’utf8’. The third line seems to miss a _ (as utf8 is documented to be the same as UTF8 in the paragraph preceeding this). - --- Flags: category=library severity=low --- Site configuration information for perl v5.8.6: Configured by Marc Lehmann at Tue Nov 30 00:54:44 CET 2004. Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=linux, osvers=2.6.10-rc1, archname=amd64-linux uname='linux cerebro 2.6.10-rc1 #1 smp mon nov 22 05:47:21 cet 2004 x86_64 gnulinux ' config_args='-Duselargefiles -Dxuse64bitint -Uxuse64bitall -Dusemymalloc=y -Dcc=gcc-3.4 -Dccflags=-ggdb -Dcppflags=-D_GNU_SOURCE -I/opt/include -Doptimize=-O4 -march=opteron -mtune=opteron -funroll-loops -fno-strict-aliasing -Dcccdlflags=-fPIC -Dldflags=-L/opt/perl/lib -L/opt/lib -Dlibs=-ldl -lm -lcrypt -Darchname=amd64-linux -Dprefix=/opt/perl -Dprivlib=/opt/perl/lib/perl5 -Darchlib=/opt/perl/lib/perl5 -Dvendorprefix=/opt/perl -Dvendorlib=/opt/perl/lib/perl5 -Dvendorarch=/opt/perl/lib/perl5 -Dsiteprefix=/opt/perl -Dsitelib=/opt/perl/lib/perl5 -Dsitearch=/opt/perl/lib/perl5 -Dsitebin=/opt/perl/bin -Dman1dir=/opt/perl/man/man1 -Dman3dir=/opt/perl/man/man3 -Dsiteman1dir=/opt/perl/man/man1 -Dsiteman3dir=/opt/perl/man/man3 -Dman1ext=1 -Dman3ext=3 -Dpager=/usr/bin/less -Uafs -Uusesfio -Uusenm -Uuseshrplib -Dd_dosuid -Dusethreads=undef -Duse5005threads=undef -Duseithreads=undef -Dusemultiplicity=undef [EMAIL PROTECTED] [EMAIL PROTECTED] -Dcf_by=Marc Lehmann -Dlocincpth=/opt/perl/include /opt/include -Dmyhostname=localhost -Dmultiarch=undef -Dbin=/opt/perl/bin -des' 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=y, bincompat5005=undef Compiler: cc='gcc-3.4', ccflags ='-ggdb -fno-strict-aliasing -pipe -I/opt/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O4 -march=opteron -mtune=opteron -funroll-loops -fno-strict-aliasing', cppflags='-D_GNU_SOURCE -I/opt/include -ggdb -fno-strict-aliasing -pipe -I/opt/include' ccversion='', gccversion='3.4.2 (Debian 3.4.2-3)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 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='gcc-3.4', ldflags ='-L/opt/perl/lib -L/opt/lib -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-ldl -lm -lcrypt perllibs=-ldl -lm -lcrypt libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/opt/perl/lib -L/opt/lib -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.6: /root/src/sex /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 /opt/perl/lib/perl5 . --- Environment for perl v5.8.6: HOME=/root LANG (unset) LANGUAGE (unset) LC_CTYPE=de_DE.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/root/s2:/root/s:/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/games:/root/src/uunet:. PERL5LIB=/root/src/sex PERL5_CPANPLUS_CONFIG=/root/.cpanplus/config PERLDB_OPTS=ornaments=0 PERL_BADLANG (unset) PERL_UNICODE=SAL SHELL=/bin/bash
++ turns undef into 0 first
This recently bit me:
$ perl -wle 'print 42 if defined($h{foo}++)'
42
Now, before thousands of you reach for the flamethrowers, yes, I know
- now - that this is documented. I found it in perlop right where it
ought to be:
| undef is always treated as numeric, and in particular is changed to 0
| before incrementing (so that a post-increment of an undef value will
| return 0 rather than undef).
The only thing that perturbs me is that I had to find this after I was
starting to wonder whether there was a bug. So this looks to me like
suboptimal behavior that has been documented; any chance of making it
behave the more logical way, i.e., that the expression evaluates to the
original value and not some modified one? I can't imagine there is much
code relying on the current behavior.
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
[perl #17650] eval: DESTROY may overwrite $@ - exceptions are not handled
I think the DESTROY method is responsible for preserving the value of
$@ --- either by appending the new $@ value to the old one or by
localizing [EMAIL PROTECTED]
There's another problem with this work-around -- it breaks in the other
direction!
tin-foil:/tmp glasser$ cat /tmp/localdie
sub i_die {
die this is why I died;
}
sub i_localize_dollar_at { # This could certainly be DESTROY
local $@;
i_die();
}
eval { i_localize_dollar_at() };
my $error = $@;
if ($error) {
print The error was: $error\n;
} else {
print There was no error. (Or was there?)\n;
}
tin-foil:/tmp glasser$ perl localdie
There was no error. (Or was there?)
That is, localizing $@ in DESTROY solves the problem of an eval inside
the DESTROY hides an error that happened before the DESTROY, but it
causes the problem that it hides an error that happens *in* the DESTROY!
I'm not sure if Alex's patch has this issue too.
--dave
Smoke [5.9.0] 25305 FAIL(m) openbsd 3.6 (i386/1 cpu)
Automated smoke report for 5.9.0 patch 25305 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 25305 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)
[perl #36950] Bizarre warning message
# New Ticket Created by Mark-Jason Dominus # Please include the string: [perl #36950] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36950 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] use Data::Dumper; open my($O), , /tmp/out; print $O Data::Dumper-Dump([], []); print OK\n; This program generates the following output: Bareword found where operator expected at /tmp/bug.pl line 4, near $O Data::Dumper (Missing operator before Data::Dumper?) OK The warning message here is inappropriate. The statement is parsed and executed correctly. Also, this warning does not appear in perldiag. [Please do not change anything below this line] - --- Flags: category=core severity=medium --- Site configuration information for perl v5.8.0: Configured by mjd at Thu Apr 17 11:57:37 EDT 2003. Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.2-2, archname=i586-linux uname='linux plover.com 2.4.2-2 #1 sun apr 8 19:37:14 edt 2001 i586 unknown ' config_args='-des' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.1 2.96-81)', 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=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.0: /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.7.3 /usr/local/lib/perl5/site_perl/5.7.2 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . --- Environment for perl v5.8.0: HOME=/home/mjd LANG=C LANGUAGE (unset) LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib LOGDIR (unset) PATH=/home/mjd/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/sbin:/usr/sbin:/usr/local/bin/X11R6:/usr/local/bin/mh:/data/mysql/bin:/usr/local/bin/pbm:/usr/local/bin/ezmlm:/home/mjd/TPI/bin:/usr/local/teTeX/bin:/usr/local/mysql/bin PERL_BADLANG (unset) SHELL=/bin/bash
Re: ++ turns undef into 0 first
On 8/18/05, Peter Scott [EMAIL PROTECTED] wrote:
This recently bit me:
$ perl -wle 'print 42 if defined($h{foo}++)'
42
Now, before thousands of you reach for the flamethrowers, yes, I know
- now - that this is documented. I found it in perlop right where it
ought to be:
| undef is always treated as numeric, and in particular is changed to 0
| before incrementing (so that a post-increment of an undef value will
| return 0 rather than undef).
This was documented by Hugo as change 19014 :
http://public.activestate.com/cgi-bin/perlbrowse?patch=19014
Hugo, any comment on this ?
The only thing that perturbs me is that I had to find this after I was
starting to wonder whether there was a bug. So this looks to me like
suboptimal behavior that has been documented; any chance of making it
behave the more logical way, i.e., that the expression evaluates to the
original value and not some modified one? I can't imagine there is much
code relying on the current behavior.
Re: [perl #36950] Bizarre warning message
Mark-Jason Dominus (via RT) wrote: use Data::Dumper; open my($O), , /tmp/out; print $O Data::Dumper-Dump([], []); print OK\n; This program generates the following output: Bareword found where operator expected at /tmp/bug.pl line 4, near $O Data::Dumper (Missing operator before Data::Dumper?) OK I can't reproduce with with either maint or blead.
[perl #36951] POSIX build fails in bleadperl
# New Ticket Created by David Dyck
# Please include the string: [perl #36951]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36951
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl vv5.9.3.
-
[Please enter your report here]
Just rsync'ed to the latest blead perl as was surprised
to get the following error (haven't dug through the diff's
to find out what might have triggered this)
Making POSIX (dynamic)
/home/dcd/CPAN/debug/ext/POSIX
Processing hints file hints/linux.pl
Note (probably harmless): No library found for -lposix
Note (probably harmless): No library found for -lcposix
Writing Makefile for POSIX
make[1]: Entering directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
make[1]: Leaving directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
make[1]: Entering directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
cp POSIX.pod ../../lib/POSIX.pod
cp POSIX.pm ../../lib/POSIX.pm
AutoSplitting ../../lib/POSIX.pm (../../lib/auto/POSIX)
../../miniperl -I../../lib -I../../lib ../../lib/ExtUtils/xsubpp
-noprototypes -typemap ../../lib/ExtUtils/typemap -typem
ap typemap POSIX.xs POSIX.xsc mv POSIX.xsc POSIX.c
cc -c -DPERL_DISABLE_PMC -DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BIT
S=64 -DSTRUCT_TM_HASZONE -DHINT_SC_EXIST -O3 -g -DVERSION=\1.09\
-DXS_VERSION=\1.09\ -fpic -I../.. POSIX.c
const-c.inc: In function `constant_8':
In file included from POSIX.xs:395:
const-c.inc:2010: `_NSIG' undeclared (first use in this function)
const-c.inc:2010: (Each undeclared identifier is reported only once
const-c.inc:2010: for each function it appears in.)
make[1]: *** [POSIX.o] Error 1
make[1]: Leaving directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
make: *** [lib/auto/POSIX/POSIX.so] Error 2
#define PERL_REVISION 5 /* age */
#define PERL_VERSION9 /* epoch */
#define PERL_SUBVERSION 3 /* generation */
static const char * const local_patches[] = {
NULL
,DEVEL24148
,NULL
};
[Please do not change anything below this line]
-
---
Flags:
category=library
severity=high
---
This perlbug was built using Perl vv5.9.3 - Thu Aug 18 21:10:10 PDT 2005
It is being executed now by Perl vv5.9.3 - Wed Jul 6 21:34:06 PDT 2005.
Site configuration information for perl vv5.9.3:
Configured by dcd at Wed Jul 6 21:34:06 PDT 2005.
Summary of my perl5 (revision 5 version 9 subversion 3 patch 25088)
configuration:
Platform:
osname=linux, osvers=2.4.32-pre1, archname=i686-linux
uname='linux dd 2.4.32-pre1 #1 wed jul 6 15:56:53 pdt 2005 i686 '
config_args='-Accflags=-DPERL_DISABLE_PMC -Dmksymlinks -Dinstallusrbinperl
-Uversiononly -Dusedevel -Doptimize=-O3 -g -de [EMAIL PROTECTED]'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DPERL_DISABLE_PMC -DDEBUGGING -fno-strict-aliasing
-pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3 -g',
cppflags='-DPERL_DISABLE_PMC -DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include'
ccversion='', gccversion='egcs-2.91.66.1 19990314/Linux (egcs-1.1.2
release)', 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=4
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -ldbm -ldb -ldl -lm -lc
perllibs=-ldl -lm -lc
libc=/lib/libc.so.5.4.44, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
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 vv5.9.3:
/usr/local/lib/perl5/5.9.3/i686-linux
/usr/local/lib/perl5/5.9.3
/usr/local/lib/perl5/site_perl/5.9.3/i686-linux
/usr/local/lib/perl5/site_perl/5.9.3
/usr/local/lib/perl5/site_perl/5.9.2/i686-linux
/usr/local/lib/perl5/site_perl/5.9.2
/usr/local/lib/perl5/site_perl
.
---
Environment for perl vv5.9.3:
HOME=/home/dcd
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
Re: [perl #36951] POSIX build fails in bleadperl
David Dyck (via RT) wrote: Just rsync'ed to the latest blead perl as was surprised to get the following error (haven't dug through the diff's to find out what might have triggered this) Worksforme. Is this a clean build ?
Re: ++ turns undef into 0 first
On Fri, Aug 19, 2005 at 11:41:08AM +0200, Rafael Garcia-Suarez wrote:
On 8/18/05, Peter Scott [EMAIL PROTECTED] wrote:
This recently bit me:
$ perl -wle 'print 42 if defined($h{foo}++)'
42
Now, before thousands of you reach for the flamethrowers, yes, I know
- now - that this is documented. I found it in perlop right where it
ought to be:
| undef is always treated as numeric, and in particular is changed to 0
| before incrementing (so that a post-increment of an undef value will
| return 0 rather than undef).
This was documented by Hugo as change 19014 :
http://public.activestate.com/cgi-bin/perlbrowse?patch=19014
Hugo, any comment on this ?
I remember a borderline acerbic discussion here; perhaps someone could
read the archives and summarize what was said, rather than everyone
restating the same opinions?
Re: ++ turns undef into 0 first
Yitzchak Scott-Thoennes wrote: I remember a borderline acerbic discussion here; perhaps someone could read the archives and summarize what was said, rather than everyone restating the same opinions? This discussion doesn't appear in the P5P summaries of the time :(
Re: opcode sequence.
On Fri, Aug 19, 2005 at 01:15:07AM -0700, rajarshi das wrote: cond_expr would be there if there were an else clause. But the test doesnot contain an else clause. What I have indicated above is exactly what I run. I have run it with both sets of values for $a and $b, and both times I see the next op executed *by the main body of code* to be OP_AND. Note however, that when the match is exdcuted, match itself calls into code in utf8_heavy.pl, so the next op executed after the OP_MATCH isn't the condiition on the next line. -- The Enterprise's efficient long-range scanners detect a temporal vortex distortion in good time, allowing it to be safely avoided via a minor course correction. -- Things That Never Happen in Star Trek #21
Re: ++ turns undef into 0 first
On Fri, Aug 19, 2005 at 12:23:18PM +0200, Rafael Garcia-Suarez wrote: Yitzchak Scott-Thoennes wrote: I remember a borderline acerbic discussion here; perhaps someone could read the archives and summarize what was said, rather than everyone restating the same opinions? This discussion doesn't appear in the P5P summaries of the time :( http://groups.google.com/[EMAIL PROTECTED]
Smoke [5.9.3] 25306 FAIL(XF) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25306 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(XF) 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 25306 Configuration (common) none --- - F F - - -Duse64bitint O X - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio] -Duse64bitint ../t/op/int.t...FAILED 11 [perlio] -Duse64bitint ../lib/Net/hostent.tFAILED 4-7 ../t/op/int.t...FAILED 11 [perlio] 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: [EMAIL PROTECTED] Constant.t fix for VMS.
Andy Lester wrote: - rename $makefile_rename, $makefile + rename $makefile_rename, $makefile . $makefile_ext or die Can't rename '$makefile_rename' to '$makefile': $!; Shouldn't that be or die Can't rename '$makefile_rename' to '$makefile$makefile_ext': $! Something like that. I forgot about fixing the error message after I fixed what was causing the error. I won't have time to do anything about that for at least 9 hours from now. -John [EMAIL PROTECTED] Personal Opinion Only
Re: ++ turns undef into 0 first
Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
:On 8/18/05, Peter Scott [EMAIL PROTECTED] wrote:
: This recently bit me:
:
: $ perl -wle 'print 42 if defined($h{foo}++)'
: 42
:
: Now, before thousands of you reach for the flamethrowers, yes, I know
: - now - that this is documented. I found it in perlop right where it
: ought to be:
:
: | undef is always treated as numeric, and in particular is changed to 0
: | before incrementing (so that a post-increment of an undef value will
: | return 0 rather than undef).
:
:This was documented by Hugo as change 19014 :
:http://public.activestate.com/cgi-bin/perlbrowse?patch=19014
:Hugo, any comment on this ?
I'd much rather the behaviour were as Peter requests, but my synopsis
in the thread covers my reasoning.
Hugo
Re: Encoding iso-8859-16
On Fri, Aug 19, 2005 at 05:01:04PM +0530, Sastry wrote: Hi Nicholas With reference to my previous mail on encoding module use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print \n String: $string\n; print \n enc_string: $enc_string\n; a)How different are those ext/Encode/def_t.c and ext/Encode/Byte/byte_t.c files in EBCDIC and ASCII platforms? I don't know. I have no experience of EBCDIC. The files describe converting from perl's internal representation to a fixed external representation. So I assume that they have to differ because the internal representation differs. b) Why is it when I copied the above .c files from ASCII platform to EBCDIC worked for any codepage except IBM-1047 codepage on EBCDCI platform? I don't know. How thorough are the tests? Do the tests check for the conversion of characters with Unicode code points 127? You're asking questions beyond my knowledge. Nicholas Clark
Re: ++ turns undef into 0 first
[EMAIL PROTECTED] wrote:
Rafael Garcia-Suarez [EMAIL PROTECTED] wrote:
:On 8/18/05, Peter Scott [EMAIL PROTECTED] wrote:
: This recently bit me:
:
: $ perl -wle 'print 42 if defined($h{foo}++)'
: 42
:
: Now, before thousands of you reach for the flamethrowers, yes, I know
: - now - that this is documented. I found it in perlop right where it
: ought to be:
:
: | undef is always treated as numeric, and in particular is changed to 0
: | before incrementing (so that a post-increment of an undef value will
: | return 0 rather than undef).
:
:This was documented by Hugo as change 19014 :
:http://public.activestate.com/cgi-bin/perlbrowse?patch=19014
:Hugo, any comment on this ?
I'd much rather the behaviour were as Peter requests, but my synopsis
in the thread covers my reasoning.
Yes, that makes sense to me as well.
As Jan Dubois put it, Does the numeric context change the
value that the variable had retroactively?
Re: [perl #36950] Bizarre warning message
Rafael Garcia-Suarez: Mark-Jason Dominus (via RT) wrote: Bareword found where operator expected at /tmp/bug.pl line 4, near $O Data::Dumper (Missing operator before Data::Dumper?) I can't reproduce with with either maint or blead. I just grepped blead sources, and the warning does not appear there, so it doesn't need to be added to perldiag, either. Thanks.
[ANNOUNCE] CPANPLUS-0.056_01
Hello, I'm pleased to announce the 0.056_01 development release of CPANPLUS. This release mainly entails the splitting out of CPANPLUS::Dist::Build (the sub-module for dealing with Module::Build based packages) into it's own CPAN-package. Below is the changelog for this release. You can get it from: http://cpanplus.xs4all.nl/~kane/CPANPLUS-0.056_01.tar.gz Or soon from a CPAN near you. Any feedback on this developer release is appreciated, especially if you encounter issues on less-widely spread operating systems or configurations. I'd like to thank again everyone who worked hard on this to make this release possible; the developers, testers and idea- fairies ;) Changes for 0.056_01Thu Aug 18 16:26:52 CEST 2005 = * This is a development release testing the splitting off of CPANPLUS::Dist::Buid into it's own package, several bugfixes and a few small features. * Make 'i URI' work from the default shell, enabling commands like 'i http://example.com/module.tgz'. parse_module() understands this as well (for API users) -- #11479 * CPANPLUS::Dist::Deb got branched into it's own package * Add test cases for lack of CPANPLUS::Dist::Deb * Add new test tarballs that provide the simples possible distributions * Add prereq to CPANPLUS::Dist::Build if the user prefers to use Build.PL over Makefile.PL * Add a depencendency on Win32::Process on Win32 (bundled with AS perl, needed by IPC::Run) * Quell warnings about empty prerequisite lists (#13111) * Quell warnings about beta-versions being non-numeric (#14106) * Platform dependant modules were /always/ getting an NA grade regardless whether they failed or not (#13224) * Config keys are now sorted when printed in the default shell (as requested by Tux) * Extracted files now only get +w for the owner, not '755', as this interferes with some modules test suite (#13358) * Some modules uses module_name_version.ext rather than the usual module-name-version.ext. CPANPLUS now parses both correctly (#13367) * 's mirrors' in the default shell now lists your mirrors. To alter them you must still edit the config using 's edit' * Buffers are now autoflushed while invoking 'perl Makefile.PL'; Modules that asked questions during interactive install sometimes had their output held back in the buffer. Since not all modules do $|++ in their Makefile.PL, we do it for them (#12121) * The diagnostic reporting functions 'msg' and 'error' from CPANPLUS::Error got renamed to 'cp_msg' and 'cp_error' respectively, to avoid conflicts with Log::Message::Simple. (This only affects API developers). * All bundled modules are updated to their most recent version. -- Jos Boumans Whenever you find you are on the side of the majority, it is time to pause and reflect. - Mark Twain CPANPLUShttp://cpanplus.sf.net
Re: Encoding iso-8859-16
On Fri, Aug 19, 2005 at 05:51:10PM +0530, Sastry wrote: Hi The test case uses the invariant character that is below 127 on ISO-8859-16 codepage. Since character 'a' has a codepoint of 129 on EBCDIC, is there a place in the code where it should apply NATIVE_TO_ASCII macro on the input character? I don't know. And if the test is only checking for invariant characters below 127, it doesn't strike me as a very thorough test. Nicholas Clark
Re: [PATCH] make threads.xs emit warnings properly
On 8/7/05, Tassilo von Parseval [EMAIL PROTECTED] wrote: Hi, the attached patch wraps ckWARN_d around the Perl_warn calls in threads.xs so that these default warnings can be switched off using no warnings 'threads' or the -X switch. Also included the corresponding changes to perldiag.pod. Thanks, applied as change #25307.
Re: Encoding iso-8859-16
Hi Nicholas With reference to my previous mail on encoding module use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print \n String: $string\n; print \n enc_string: $enc_string\n; a)How different are those ext/Encode/def_t.c and ext/Encode/Byte/byte_t.c files in EBCDIC and ASCII platforms? b) Why is it when I copied the above .c files from ASCII platform to EBCDIC worked for any codepage except IBM-1047 codepage on EBCDCI platform? I stepped in the code and saw that in encengine.c the e-seq is different on both the platforms. I guess that the structure is not properly set. Please throw any thoughts you have! -Sastry On 8/9/05, Sastry [EMAIL PROTECTED] wrote: Hi Nicholas Clark I agree that it is supposed to print the numerical equivalent 97. I attempted to see if there is any bug in the encode module. Surprisingly, I noticed that there are two .c files in ext/Encode/def_t.c and ext/Encode/Byte/byte_t.c which are generated using enc2xs. They are different on EBCDIC platform and ASCII platform like Linux. I just replaced those files from linux onto EBCDIC which gave the expected result '97' Please let me know if those .c files should be the same on both the platform! -Sastry On 8/9/05, Nicholas Clark [EMAIL PROTECTED] wrote: On Tue, Aug 09, 2005 at 10:58:48AM +0530, Sastry wrote: Hi I get 73 printed on EBCDIC platform. I think it is supposed to print 129 as it is the numeric equivalent of 'a'. -Sastry On 8/8/05, Nicholas Clark [EMAIL PROTECTED] wrote: On your EBCDIC platform, what does this give? It prints 73 use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print ord ($enc_string), \n; 73. Odd. It should print 97 on all platforms. Because: $string contains 1 byte, the byte that represents 'a' in the platform's default character encoding. The encode call should convert from the default encoding to iso-8859-16 And 'a' in iso-8859-16 is 97. Everywhere. So $enc_string should be a single byte, 97, everywhere. Nicholas Clark
Re: Data::Dumper bug?
Yitzchak Scott-Thoennes wrote:
On Mon, Aug 08, 2005 at 12:08:13PM -0500, Troy Loveday wrote:
Gurusamy,
Ilya Martynov is now the Data::Dumper maintainer.
I have observed what I consider to be a bug in XS (C) implementation of
Data::Dumper (the Perl implementation does not exhibit the problem).
Problem: With Sortkeys(1), it leaves hash iterators in an indeterminate
state. Subsequent code must reset the hash iterator with
keys %hash (see perldoc -q reset).
Good catch. It was uselessly iterating through the hash a second time
after sorting, once for each key, so the iterator would be left at the
end.
--- perl/ext/Data/Dumper/Dumper.xs.orig 2005-06-21 03:08:44.0 -0700
+++ perl/ext/Data/Dumper/Dumper.xs 2005-08-08 19:58:15.415064000 -0700
@@ -614,9 +614,11 @@ DD_dump(pTHX_ SV *val, const char *name,
I32 nlen;
bool do_utf8 = FALSE;
-if ((sortkeys !(keys (I32)i = av_len(keys))) ||
-!(entry = hv_iternext((HV *)ival)))
-break;
+ if (sortkeys) {
+ if (!(keys (I32)i = av_len(keys))) break;
+ } else {
+ if (!(entry = hv_iternext((HV *)ival))) break;
+ }
if (i)
sv_catpvn(retval, ,, 1);
End of Patch.
I resisted the temptation to use ?: in the if condition :)
Thanks, applied as change #25308 to bleadperl.
I'm not sure how to test for that, however...
Re: [perl #36950] Bizarre warning message
On Thu, Aug 18, 2005 at 08:58:55PM -0700, Mark-Jason Dominus wrote: This program generates the following output: Bareword found where operator expected at /tmp/bug.pl line 4, near $O Data::Dumper (Missing operator before Data::Dumper?) OK The warning message here is inappropriate. The statement is parsed and executed correctly. Also, this warning does not appear in perldiag. It does appear, but the first word is variable: %s found where operator expected (S) The Perl lexer knows whether to expect a term or an operator. If it sees what it knows to be a term when it was expecting to see an operator, it gives you this warning. Usually it indicates that an operator or delimiter was omitted, such as a semicolon. Ronald
Re: [perl #36950] Bizarre warning message
Ronald Kimball: On Thu, Aug 18, 2005 at 08:58:55PM -0700, Mark Jason Dominus wrote: Also, this warning does not appear in perldiag. It does appear, but the first word is variable: Thanks.
Re: RFC - eliminate discrete arenaroots
Tels wrote:
-BEGIN PGP SIGNED MESSAGE-
Moin,
Jim Cromie [EMAIL PROTECTED] wrote:
attached is an almost-there patch which:
replaces most arena-root pointers with an array of them
replaces same root pointers with array.
simplifies several macros using them.
the line-count doesnt shrink much, but it simplifies source code, and
shrinks object code:
I didn't understand this comparisation fully. Are this bytes used by the
functions?
(I was brief here, cuz Ive posted on this topic b4, w/o any response)
bytes ? assuming you meant pointers, heres some elaboration.
(theres lots of good commentary in sv.c)
most of the body types are allocated from arenas rather than from malloc,
to avoid malloc overhead, and to be able to report un-reclaimed vars during
final cleanup.
when theyre needed, the arenas are added to the front of the chain pointed
to by ~14 separate/discrete (and typed) pointers, all of which are part of
the interpreter structure. The 14 different types leads to lots of
macro ##
convolutions (which is an improvement over the previous cut-paste
duplication),
and large switches full of closely related code.
replacing the typed pointers with an array of void pointers, and
adding a couple of svtype indexed lookups makes it possible to
simplify and/or strip some of the macros.
Only some of that cleanup is done thus far.
Anyway, this work sounds good. Just one small detail:
+
+for (i=0; i17; i++) {
+ S_free_arena(aTHX_ (void**) PL_body_arenaroots[i]);
+ PL_body_arenaroots[i] = 0;
+ PL_body_roots[i] = 0;
+}
The 17 should be defined somewhere. It might change someday :)
true. never say never - but it hasnt been touched since 5.00503.
If it changed, B.xs would break too, theres a hard-coded correspondence
between
the svtype and svclassnames. A svtype_info struct could solve that,
but would add some (minor) overhead. (svclassnames isnt in sv.h to
avoid just that)
+ Note that 1st 4 sv-types have no bodies,
+ *_allocated bodies are smaller cuz they have unused slots.
+*/
I do not like the abbrevitation cuz. I sometimes use w/ and w/o, but
u dont ? :-P ok fair enough.
I'll wait a while, perhaps others will offer feedback.
Im happy to add minor tweaks as a pre/post-condition to application ;-)
the former is already borderline for me. I think you have the time to
spell comments out. Otherwise we will see comments like this one next:
/* 4 u we r ! d0ing teh all0cat'n */
:-D
Best wishes,
Tels
thanks
jimc
Re: [perl #36951] POSIX build fails in bleadperl
On Fri, 19 Aug 2005 at 12:07 +0200, Rafael Garcia-Suarez [EMAIL PROTECTED]: From: Rafael Garcia-Suarez [EMAIL PROTECTED] David Dyck (via RT) wrote: Just rsync'ed to the latest blead perl as was surprised to get the following error (haven't dug through the diff's to find out what might have triggered this) Worksforme. Is this a clean build ? Yes. This is an older libc5 base 'slackware' system with a 2.4.32-pre1 kernel that has had trouble with signals before. I think special code had been added to configure to test all the signals individually. I was surprised when these failures occured in the POSIX build - even though miniperl build fine.
Re: resolving methods at compile time
On Wed, Aug 17, 2005 at 12:00:18PM -0700, Philippe M. Chiasson wrote: This somewhat simplistic benchmark seems to indicate there actually is a performance hit to using that form of my statement snip $ perl-5.8.6 bench-my.pl declared 127166/s -- -6% normal 134590/s 6% -- $ perl5.8.6 ~/tmp/foo.plx Rate declared normal declared 162068/s -- -1% normal 163959/s 1% -- $ perl5.8.6 ~/tmp/foo.plx Rate declared normal declared 162444/s -- -0% normal 162474/s 0% -- $ perl5.8.6 ~/tmp/foo.plx Rate declared normal declared 162103/s -- -0% normal 162893/s 0% -- $ perl5.6.2 ~/tmp/foo.plx Benchmark: running declared, normal, each for at least 15 CPU seconds... declared: 19 wallclock secs (15.56 usr + 0.00 sys = 15.56 CPU) @ 119003.86/s (n=1851700) normal: 18 wallclock secs (15.35 usr + 0.09 sys = 15.44 CPU) @ 121247.47/s (n=1872061) Rate declared normal declared 119004/s -- -2% normal 121247/s 2% -- $ perl5.6.2 ~/tmp/foo.plx Benchmark: running declared, normal, each for at least 15 CPU seconds... declared: 18 wallclock secs (14.92 usr + 0.09 sys = 15.01 CPU) @ 124462.43/s (n=1868181) normal: 18 wallclock secs (15.55 usr + 0.03 sys = 15.58 CPU) @ 116665.02/s (n=1817641) Rate normal declared normal 116665/s -- -6% declared 124462/s 7% -- $ perl5.6.2 ~/tmp/foo.plx Benchmark: running declared, normal, each for at least 15 CPU seconds... declared: 17 wallclock secs (15.94 usr + 0.00 sys = 15.94 CPU) @ 120326.35/s (n=1918002) normal: 16 wallclock secs (15.62 usr + 0.03 sys = 15.65 CPU) @ 120341.15/s (n=1883339) Rate declared normal declared 120326/s -- -0% normal 120341/s 0% -- No significant difference from where I'm sitting. Different OSs, different compilers, different versions of Perl and a heavy dose of Benchmark.pm flutter. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [EMAIL PROTECTED] Constant.t fix for VMS.
On Thu, Aug 18, 2005 at 08:49:52PM -0400, John E. Malmberg wrote: This test script was not using the same names for the VMS specific files descrip.mms and descrip.mms_old that the rest of Makemaker was doing. ExtUtils::Constant is not part of MakeMaker. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Re: [perl #36950] Bizarre warning message
On Fri, Aug 19, 2005 at 09:27:50AM -0400, Ronald J Kimball wrote: On Thu, Aug 18, 2005 at 08:58:55PM -0700, Mark-Jason Dominus wrote: This program generates the following output: Bareword found where operator expected at /tmp/bug.pl line 4, near $O Data::Dumper (Missing operator before Data::Dumper?) OK The warning message here is inappropriate. The statement is parsed and executed correctly. Also, this warning does not appear in perldiag. It does appear, but the first word is variable: %s found where operator expected (S) The Perl lexer knows whether to expect a term or an operator. If it sees what it knows to be a term when it was expecting to see an operator, it gives you this warning. Usually it indicates that an operator or delimiter was omitted, such as a semicolon. A brief plug for perl's splain utility, which applies use diagnostics to error/warning input on stdin: $ echo Bareword found where operator expected | splain Bareword found where operator expected (#1) (S syntax) The Perl lexer knows whether to expect a term or an operator. If it sees what it knows to be a term when it was expecting to see an operator, it gives you this warning. Usually it indicates that an operator or delimiter was omitted, such as a semicolon.
Re: [perl #36951] POSIX build fails in bleadperl (RTMAX patch)
On Fri, 19 Aug 2005 at 08:24 -0700, David Dyck [EMAIL PROTECTED] wrote:
On Fri, 19 Aug 2005 at 12:07 +0200, Rafael Garcia-Suarez
[EMAIL PROTECTED]:
From: Rafael Garcia-Suarez [EMAIL PROTECTED]
David Dyck (via RT) wrote:
Just rsync'ed to the latest blead perl as was surprised
to get the following error (haven't dug through the diff's
to find out what might have triggered this)
Worksforme. Is this a clean build ?
Yes. This is an older libc5 base 'slackware' system with
a 2.4.32-pre1 kernel that has had trouble with signals
before. I think special code had been added to configure
to test all the signals individually. I was surprised when
these failures occured in the POSIX build - even though miniperl
build fine.
Just wanted to collect some more info for this bug report
The error
const-c.inc:2010: `_NSIG' undeclared (first use in this function)
is from the lines
#ifdef SIGRTMAX
*iv_return = SIGRTMAX;
return PERL_constant_ISIV;
#else
return PERL_constant_NOTDEF;
#endif
where my asm/signal.h (inherited libc5 style
from the 2.4 kernel sources) has SIGRTMAX
/* These should not be considered constants from userland. */
#define SIGRTMIN32
#define SIGRTMAX(_NSIG-1)
but _NSIG is only defined when compiling the kernel (#ifdef __KERNEL__)
sig_name
Configure tests for, and doesn't place RTMAX in sig_name
$ perl -le ' use Config; print $Config{sig_name}'
reports:
ZERO HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM
TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF
WINCH IO PWR SYS CLD IOT POLL UNUSED
So now I'm wondering, why if Configure knows which signal names
are valid, does ext/POSIX/Makefile.pl seem to ignore this.
It looks like the patch triggered the problem, and since
I hadn't rebuild my perl since July 6, I didn't notice it till
now.
+
+[ 25185] By: merijnon 2005/07/19 11:06:22
+Log: Subject: [PATCH] allow POSIX SIGRTMIN...SIGRTMAX signals (and
plug a core dump)
+ From: Jarkko Hietaniemi [EMAIL PROTECTED]
+ Date: Tue, 19 Jul 2005 12:06:00 +0300
+ Message-ID: [EMAIL PROTECTED]
+ Branch: perl
+ ! Configure ext/POSIX/Makefile.PL ext/POSIX/POSIX.pm
+ ! ext/POSIX/POSIX.pod ext/POSIX/POSIX.xs ext/POSIX/t/sigaction.t
+ ! handy.h
Re: Data::Dumper bug?
On Fri, Aug 19, 2005 at 03:21:25PM +0200, Rafael Garcia-Suarez wrote:
Date: Fri, 19 Aug 2005 15:21:25 +0200
From: Rafael Garcia-Suarez [EMAIL PROTECTED]
To: Yitzchak Scott-Thoennes [EMAIL PROTECTED]
Cc: Troy Loveday [EMAIL PROTECTED], perl5-porters@perl.org,
Ilya Martynov
[EMAIL PROTECTED]
Subject: Re: Data::Dumper bug?
In-Reply-To: [EMAIL PROTECTED]
X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i586-mandrake-linux-gnu)
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0
adultscore=0 adjust=0 reason=mlx engine=3.0.0-05081600
definitions=3.0.0-05081903
Yitzchak Scott-Thoennes wrote:
On Mon, Aug 08, 2005 at 12:08:13PM -0500, Troy Loveday wrote:
Gurusamy,
Ilya Martynov is now the Data::Dumper maintainer.
I have observed what I consider to be a bug in XS (C) implementation of
Data::Dumper (the Perl implementation does not exhibit the problem).
Problem: With Sortkeys(1), it leaves hash iterators in an indeterminate
state. Subsequent code must reset the hash iterator with
keys %hash (see perldoc -q reset).
Good catch. It was uselessly iterating through the hash a second time
after sorting, once for each key, so the iterator would be left at the
end.
--- perl/ext/Data/Dumper/Dumper.xs.orig 2005-06-21 03:08:44.0 -0700
+++ perl/ext/Data/Dumper/Dumper.xs 2005-08-08 19:58:15.415064000 -0700
@@ -614,9 +614,11 @@ DD_dump(pTHX_ SV *val, const char *name,
I32 nlen;
bool do_utf8 = FALSE;
-if ((sortkeys !(keys (I32)i = av_len(keys))) ||
-!(entry = hv_iternext((HV *)ival)))
-break;
+ if (sortkeys) {
+ if (!(keys (I32)i = av_len(keys))) break;
+ } else {
+ if (!(entry = hv_iternext((HV *)ival))) break;
+ }
if (i)
sv_catpvn(retval, ,, 1);
End of Patch.
I resisted the temptation to use ?: in the if condition :)
Thanks, applied as change #25308 to bleadperl.
I'm not sure how to test for that, however...
Try the following:
use strict;
use warnings;
#
# Version 2.121 of Data::Dumper has this bug.
#
use Data::Dumper;
sub iterate_hash
{
my ($hashref) = @_;
my $count = 0;
$count++ while ( each %{$hashref} );
return $count;
}
my $dumper = Data::Dumper-new( [\%ENV], ['ENV'] )
# WORKAROUND
#-Useperl(1)
-Sortkeys(1);
printf(ENV interations: %d\n, iterate_hash(\%ENV));
$dumper-Dump;
# WORKAROUND
#keys %ENV;
printf(ENV interations: %d\n, iterate_hash(\%ENV));
--
Troy Lovedaye-mail: [EMAIL PROTECTED]
WW Make IT Factory Systems Solutions phone: 214-567-6463
Texas Instruments, Inc.
Plano, Texas
[perl #36953] Uppercase Lowercase is not working on Turkish Characters
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36953]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36953
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.5.
-
[Please enter your report here]
Following perl program :
===
use POSIX;
setlocale(LC_CTYPE, tr_TR.UTF-8);
printf(%s %s\n, uc(abğıi),lc(ABĞIİ));
===
outputs :
ABğıI abĞiİ
but it should output:
ABĞIİ abğiı
Because in turkish locale uppercase('i') = İ where as lowercase('I') = ı .
LC_ALL set to tr_TR.UTF-8 .
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.5:
Configured by Gentoo at Fri May 13 15:15:00 EEST 2005.
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=linux, osvers=2.6.10-uludag, archname=i686-linux
uname='linux paketler.uludag.org.tr 2.6.10-uludag #1 wed jan 26 16:42:26
eet 2005 i686 intel(r) pentium(r) 4 cpu 2.60ghz genuineintel gnulinux '
config_args='-des -Darchname=i686-linux -Dcccdlflags=-fPIC
-Dccdlflags=-rdynamic -Dcc=gcc -Dprefix=/usr -Dvendorprefix=/usr
-Dsiteprefix=/usr -Dlocincpth= -Doptimize=-mcpu=i686 -O2 -pipe
-fomit-frame-pointer -Duselargefiles -Dd_semctl_semun -Dscriptdir=/usr/bin
-Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3
-Dinstallman1dir=/usr/share/man/man1
-Dinstallman3dir=/var/tmp/portage/perl-5.8.5-r5/image//usr/share/man/man3
-Dman1ext=1 -Dman3ext=3pm -Dinc_version_list=5.8.0 5.8.0/i686-linux 5.8.2
5.8.2/i686-linux 5.8.4 5.8.4/i686-linux -Dcf_by=Gentoo -Ud_csh -Di_ndbm
-Di_gdbm -Di_db'
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=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-mcpu=i686 -O2 -pipe -fomit-frame-pointer',
cppflags='-DPERL5 -fno-strict-aliasing -pipe'
ccversion='', gccversion='3.3.5-20050130 (Pardus Linux 3.3.5.20050130-r1,
ssp-3.3.5.20050130-1, pie-8.7.7.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='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lpthread -lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.4.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Locally applied patches:
---
@INC for perl v5.8.5:
/etc/perl
/usr/lib/perl5/site_perl/5.8.5/i686-linux
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.4/i686-linux
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i686-linux
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.5/i686-linux
/usr/lib/perl5/5.8.5
/usr/local/lib/site_perl
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.4/i686-linux
.
---
Environment for perl v5.8.5:
HOME=/home/cartman
LANG=tr_TR.UTF-8
LANGUAGE (unset)
LC_ALL=tr_TR.UTF-8
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/lib/ccache/bin:/home/cartman/SVN/kdenonbeta/unsermake:/usr/kde/3.4/bin:/usr/lib/ccache/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin:/usr/qt/3/bin:/usr/kde/3.4/bin
PERL_BADLANG (unset)
SHELL=/bin/bash
Re: Encoding iso-8859-16
Hi The test case uses the invariant character that is below 127 on ISO-8859-16 codepage. Since character 'a' has a codepoint of 129 on EBCDIC, is there a place in the code where it should apply NATIVE_TO_ASCII macro on the input character? -Sastry On 8/19/05, Nicholas Clark [EMAIL PROTECTED] wrote: On Fri, Aug 19, 2005 at 05:01:04PM +0530, Sastry wrote: Hi Nicholas With reference to my previous mail on encoding module use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print \n String: $string\n; print \n enc_string: $enc_string\n; a)How different are those ext/Encode/def_t.c and ext/Encode/Byte/byte_t.c files in EBCDIC and ASCII platforms? I don't know. I have no experience of EBCDIC. The files describe converting from perl's internal representation to a fixed external representation. So I assume that they have to differ because the internal representation differs. b) Why is it when I copied the above .c files from ASCII platform to EBCDIC worked for any codepage except IBM-1047 codepage on EBCDCI platform? I don't know. How thorough are the tests? Do the tests check for the conversion of characters with Unicode code points 127? You're asking questions beyond my knowledge. Nicholas Clark
Re: [perl #36953] Uppercase Lowercase is not working on Turkish Characters
On Fri, Aug 19, 2005 at 04:49:28AM -0700, ismail @ uludag. org. tr wrote: === use POSIX; setlocale(LC_CTYPE, tr_TR.UTF-8); printf(%s %s\n, uc(abğıi),lc(ABĞIİ)); === outputs : ABğıI abĞiİ but it should output: ABĞIİ abğiı If you include literal utf8 characters in your program's source file, then you need to tell perl that it's utf8. Aslo, if you're printing utf8 characters to STDOUT, you need to tell perl that STDOUT should be utf8: use POSIX; setlocale(LC_CTYPE, tr_TR.UTF-8); use utf8; binmode STDOUT, ':utf8'; printf(%s %s\n, uc(abğıi),lc(ABĞIİ)); $ perl585 /tmp/x1 ABĞII abğii̇ $ -- The GPL violates the U.S. Constitution, together with copyright, antitrust and export control laws -- SCO smoking crack again.
Re: [perl #36951] POSIX build fails in bleadperl (RTMAX patch)
On Fri, 19 Aug 2005, David Dyck wrote: Yes. This is an older libc5 base 'slackware' system with a 2.4.32-pre1 kernel that has had trouble with signals before. I think special code had been added to configure to test all the signals individually. I was surprised when these failures occured in the POSIX build - even though miniperl build fine. Just wanted to collect some more info for this bug report The error const-c.inc:2010: `_NSIG' undeclared (first use in this function) is from the lines #ifdef SIGRTMAX *iv_return = SIGRTMAX; return PERL_constant_ISIV; #else return PERL_constant_NOTDEF; #endif where my asm/signal.h (inherited libc5 style from the 2.4 kernel sources) has SIGRTMAX /* These should not be considered constants from userland. */ #define SIGRTMIN32 #define SIGRTMAX(_NSIG-1) In newer glibc2-based systems, SIGRTMAX is defined to be a C library function: __libc_current_sigrtmax(). but _NSIG is only defined when compiling the kernel (#ifdef __KERNEL__) only on such hybrid 2.4.x/libc5 systems, I'd bet. I'd call this a bug in the headers, but we should still work around it. Yes, Configure has previously tested each individual signal, but it's not stored as a really simple config.h #ifdef. One could do a runtime lookup for the string RTMAX in the sign_name[] array, I suppose. It'd probably work just as well to change the test to something like the following to ensure that SIGRTMAX is indeed set to something numeric. #if defined(SIGRTMAX) SIGRTMAX SIGRTMIN -- Andy Dougherty [EMAIL PROTECTED]
Re: Data corruption - [EMAIL PROTECTED] - PERL_HV_ARRAY_ALLOC_BYTES?
Sorry about the delay in replying. I've had a lot on, and wanted to find
the time to confirm my suspicions.
On Sat, Jul 30, 2005 at 09:50:40PM -0400, John E. Malmberg wrote:
What I have found is that in this case is that the allocation size for
the sv_u.svu_array member appears to be too small.
I don't believe this conclusion to be correct.
I refactored the hash code about 2 months ago and introduced the xpvhv_aux
structure. Prior to this, the malloc()ed region pointed to by the
sv_u.svu_array member was only used for the HE*s. For the case of no the
xpvhv_aux structure, the part of the code that calculates the size to allocate
has not changed.
The size of the allocated or reallocated array is controlled by the
xhv_max member.
DBG exam hv-sv_any-xhv_max
HV\Perl_hv_iternext_flags\hv-sv_any-xhv_max: 7
The actual calculation is for the array size =
PERL_HV_ARRAY_ALLOC_BYTES(HvMAX(hv) + 1) + sizeof(struct xpvfhv_aux)
HvMAX(hv) = 7 from above.
So PERL_HV_ARRAY_ALLOC_BYTES results in:
(8 * sizeof(HE*) + sizeof(struct xpvfhv_aux)
The size of a Pointer type on VMS is 4 bytes. And the size of the
struct xpvfhv is 12 bytes. This results in (8 * 4) + 12 or 48 bytes.
A pointer to the xpvfhv is then stored in hv-sv_u.svu_array[8].
The size of the svu_array type is 12, so the offset is 12 * (8-1) is 84
which is a bit beyond the 48 bytes that was allocated.
It appears to me that macro PERL_HV_ARRAY_ALLOC_BYTES should be using
the size of the HE structure instead of the size of a pointer to that
structure.
The memory that is allocated is used to store an array of HE * pointers.
Not HE structures. The code isn't clear, and when I started trying to
investigate I realised that I could add another member to the sv_u
union, of type HE **, to make things much clearer.
Had the calculation been wrong in the past, we would also have been allocating
4*n bytes on many systems, yet using 12*n bytes, for every hash, which should
have shown up with memory checking tools (and random corruption) left right
and centre.
So I'm assuming that the problem is in or related to the changes I made to
tag a xpvhv_aux structure on the end, but not all the time. Hence I suspect
that it's my fault and been trying to confirm where, and nail the cause, if
not find the solution. But I admit that I have to give up. I don't know
where. Even if I try this change to make the xpvhv_aux structure rather
larger:
//depot/perl/hv.h#76 - /home/nick/p4perl/perl/hv.h
--- /tmp/tmp.89859.0Fri Aug 19 21:38:03 2005
+++ /home/nick/p4perl/perl/hv.h Wed Aug 17 13:54:08 2005
@@ -37,10 +37,14 @@ struct shared_he {
Don't access this directly.
*/
struct xpvhv_aux {
+char splat1[1];
HEK*xhv_name; /* name, if a symbol table */
HE *xhv_eiter; /* current entry of iterator */
I32xhv_riter; /* current root of iterator */
+char splat2[1];
};
+
+#define SPLAT(hv) memset(HvAUX(hv)-splat1, 0xFE, 1);
memset(HvAUX(hv)-splat2, 0xFE, 1);
/* hash structure: */
/* This structure must match the beginning of struct xpvmg in sv.h. */
and put calls to SPLAT everywhere that the members of xpvhv_aux are written
to, I can't trigger the corruption on x86 Linux.
The xpvhv_aux structure is placed in memory directly after the array of
pointers to HE*s. However, memory to hold it is not always allocated.
My assumption is that either
1: There's a code path that starts writing to the location it should be in,
without first calling realloc() to allocate memory for it.
2: There's an error in the code that works out the offset of the xpvhv_aux
structure given the pointer accessed via the macro HvARRAY()
but I can't find it by inspection, and I can't reproduce it, even by tweaking
the code to try to provoke the problem. Running regression tests under
valgrind doesn't find anything amiss either. I'm stuck. But I'm confident
that it's not a three-fold error in the calculation for the size of memory to
allocate for the array of HE **s.
Nicholas Clark
Re: RFC - eliminate discrete arenaroots
On Fri, Aug 19, 2005 at 11:26:46AM +0200, Tels wrote:
-BEGIN PGP SIGNED MESSAGE-
Moin,
Anyway, this work sounds good. Just one small detail:
+
+for (i=0; i17; i++) {
+ S_free_arena(aTHX_ (void**) PL_body_arenaroots[i]);
+ PL_body_arenaroots[i] = 0;
+ PL_body_roots[i] = 0;
+}
The 17 should be defined somewhere. It might change someday :)
I wasn't sure why the 17 was 17 and not 16.
Anyway, nice. This seems a good way to go.
It wasn't directly what I had been thinking about, and it had never occurred
to me to put the arena heads into an array. That's going to reduce the size
of the switch statements nicely.
What I had been wondering was whether the arena roots (or at least all bar
sv_arenaroot) can all be replaced by a single pointer, given that all that
the PL_*_arenaroot pointers point to are structurally identical linked lists
of things to free.
But if that change works, it can be made after the change you're working on
here goes in.
Nicholas Clark
Re: [PATCH ext/POSIX/POSIX.xs] Whitespace
On Sat, Jul 23, 2005 at 02:32:35AM +0200, Abigail wrote: Some lines were outdented by one space. This patch fixes it. Thanks, applied (25309)(by hand, because it turned out to be faster) I don't understand how those 2 lines managed to get to outdented, as the change that created them looks consistent across all 3 hunks, and the other 2 hunks were never outdented. http://public.activestate.com/cgi-bin/perlbrowse?patch=10816 Nicholas Clark
[perl #36959] List Constructor Operator - Undefined Values
# New Ticket Created by Chris Unger
# Please include the string: [perl #36959]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36959
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.4.
-
The Perl snippet below produces different results under Perl 5.8.4,
than Perl 5.6.1 (and earlier versions).
Perl 5.6.1 (this is what I would have expected if an undefined value
is supplied as first parameter) output:
Loop 1: 0
Loop 1: 1
Loop 2: 0
Loop 2: 1
Perl 5.8.4 (also same output with Perl 5.8.7):
Loop 1:
Loop 2: 0
Loop 2: 1
OK, I consider this an application error if you use an undefined
value with the list constructor operator (..), but shouldn't the
behavior be the same between Perl 5 versions?
Code:
#!/usr/local/perl5/bin/perl
my @array = (1, 2); # this means $#array is set to 1
for $i ($value1..$#array) { # note that $value1 is undefined
print Loop 1: $i\n;
}
print \n;
for $i ($value2..$#array) { # note $value2 is also undefined
print Loop 2: $i\n;
}
-
---
Flags:
category=core
severity=low
---
Site configuration information for perl v5.8.4:
Configured by cwu21 at Thu Apr 22 16:01:31 EDT 2004.
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos cwu21awu 5.8 generic_108528-29 sun4u sparc sunw,sun-blade-100 '
config_args=''
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=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='/opt/SUNWspro/bin/cc', ccflags =' -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O',
cppflags=''
ccversion='Sun WorkShop 6 update 2 C 5.3 Patch 111679-08 2002/05/09',
gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='/opt/SUNWspro/bin/cc', ldflags =' -L/usr/lib -L/usr/ccs/lib
-L/opt/SUNWspro/WS6U2/lib -L/usr/local/lib '
libpth=/usr/lib /usr/ccs/lib /opt/SUNWspro/WS6U2/lib /usr/local/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-KPIC', lddlflags='-G -L/usr/lib -L/usr/ccs/lib
-L/opt/SUNWspro/WS6U2/lib -L/usr/local/lib'
Locally applied patches:
---
@INC for perl v5.8.4:
/usr/local/perl5/lib/5.8.4/sun4-solaris
/usr/local/perl5/lib/5.8.4
/usr/local/perl5/lib/site_perl/5.8.4/sun4-solaris
/usr/local/perl5/lib/site_perl/5.8.4
/usr/local/perl5/lib/site_perl
.
---
Environment for perl v5.8.4:
HOME=/home/cwu21
LANG=C
LANGUAGE (unset)
LC_ALL=C
LC_CTYPE=C
LD_LIBRARY_PATH=/usr/dt/lib:/usr/dt/lib/sdtimage:/usr/openwin/lib:/usr/lib:/cas/lib/sun4
LOGDIR (unset)
PATH=/usr//bin:/home/cwu21/bin/sun4:/home/cwu21/bin:/usr/local/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/opt/SUNWsmtv/bin:/cas/bin/sun4:/cas/abin/sun4:/cas/X11/sun4/bin:/usr/ccs/bin:/lprod/bin:/usr/sbin:/usr/ucb:/cas/tools/bin/sun4:/cas/X11/sun4/tools/bin:/opt/staroffice7/program:/home/cwu21/bin:/vol/ossccs/bin:/projects/gnu/bin/sun4:/usr/java/jdk1.1.4/bin:/usr/oracle/bin:/usr/local/sbin:/usr/lib/SoftPC:/usr/perl5/bin:/usr/atria/bin:/vol/pgp/sun5/bin:/opt/SUNWcluster/bin:/projects/muse3/public/bin/sol:::/usr/dt/bin:/usr/openwin/bin
PERL_BADLANG (unset)
SHELL=/bin/ksh
Re: [perl #36959] List Constructor Operator - Undefined Values
On Fri, Aug 19, 2005 at 01:35:49PM -0700, Chris Unger wrote:
Perl 5.8.4 (also same output with Perl 5.8.7):
Loop 1:
Loop 2: 0
Loop 2: 1
Code:
#!/usr/local/perl5/bin/perl
my @array = (1, 2); # this means $#array is set to 1
for $i ($value1..$#array) { # note that $value1 is undefined
print Loop 1: $i\n;
}
print \n;
for $i ($value2..$#array) { # note $value2 is also undefined
print Loop 2: $i\n;
}
Sounds like a missing mg_get somewhere.
Re: [perl #36959] List Constructor Operator - Undefined Values
On Fri, Aug 19, 2005 at 05:30:41PM -0700, Yitzchak Scott-Thoennes wrote:
On Fri, Aug 19, 2005 at 01:35:49PM -0700, Chris Unger wrote:
my @array = (1, 2); # this means $#array is set to 1
for $i ($value1..$#array) { # note that $value1 is undefined
print Loop 1: $i\n;
}
print \n;
for $i ($value2..$#array) { # note $value2 is also undefined
print Loop 2: $i\n;
}
Sounds like a missing mg_get somewhere.
Looks like it might be all over the place. From sv.h:
/* Let us hope that bitmaps for UV and IV are the same */
#define SvIV(sv) (SvIOK(sv) ? SvIVX(sv) : sv_2iv(sv))
#define SvUV(sv) (SvIOK(sv) ? SvUVX(sv) : sv_2uv(sv))
#define SvNV(sv) (SvNOK(sv) ? SvNVX(sv) : sv_2nv(sv))
#define SvIV_nomg(sv) (SvIOK(sv) ? SvIVX(sv) : sv_2iv_flags(sv, 0))
#define SvUV_nomg(sv) (SvIOK(sv) ? SvUVX(sv) : sv_2uv_flags(sv, 0))
Aren't those first three going to return the old un-mg_getted value
quite often? Should they just be
#define SvIV(sv) sv_2iv(sv)
#define SvUV(sv) sv_2uv(sv)
#define SvNV(sv) sv_2nv(sv)
or is it the responsibility of setters to do SvNIOK_off?
--
Rick Delaney
[EMAIL PROTECTED]
Re: Data corruption - [EMAIL PROTECTED] - PERL_HV_ARRAY_ALLOC_BYTES?
Nicholas Clark wrote:
Sorry about the delay in replying. I've had a lot on, and wanted to find
the time to confirm my suspicions.
On Sat, Jul 30, 2005 at 09:50:40PM -0400, John E. Malmberg wrote:
What I have found is that in this case is that the allocation size for
the sv_u.svu_array member appears to be too small.
I don't believe this conclusion to be correct.
I refactored the hash code about 2 months ago and introduced the xpvhv_aux
structure. Prior to this, the malloc()ed region pointed to by the
sv_u.svu_array member was only used for the HE*s. For the case of no the
xpvhv_aux structure, the part of the code that calculates the size to allocate
has not changed.
The memory that is allocated is used to store an array of HE * pointers.
Not HE structures. The code isn't clear, and when I started trying to
investigate I realised that I could add another member to the sv_u
union, of type HE **, to make things much clearer.
Had the calculation been wrong in the past, we would also have been allocating
4*n bytes on many systems, yet using 12*n bytes, for every hash, which should
have shown up with memory checking tools (and random corruption) left right
and centre.
So I'm assuming that the problem is in or related to the changes I made to
tag a xpvhv_aux structure on the end, but not all the time. Hence I suspect
that it's my fault and been trying to confirm where, and nail the cause, if
not find the solution. But I admit that I have to give up. I don't know
where. Even if I try this change to make the xpvhv_aux structure rather
larger:
//depot/perl/hv.h#76 - /home/nick/p4perl/perl/hv.h
--- /tmp/tmp.89859.0Fri Aug 19 21:38:03 2005
+++ /home/nick/p4perl/perl/hv.h Wed Aug 17 13:54:08 2005
@@ -37,10 +37,14 @@ struct shared_he {
Don't access this directly.
*/
struct xpvhv_aux {
+char splat1[1];
HEK*xhv_name; /* name, if a symbol table */
HE *xhv_eiter; /* current entry of iterator */
I32xhv_riter; /* current root of iterator */
+char splat2[1];
};
+
+#define SPLAT(hv) memset(HvAUX(hv)-splat1, 0xFE, 1);
memset(HvAUX(hv)-splat2, 0xFE, 1);
/* hash structure: */
/* This structure must match the beginning of struct xpvmg in sv.h. */
and put calls to SPLAT everywhere that the members of xpvhv_aux are written
to, I can't trigger the corruption on x86 Linux.
The xpvhv_aux structure is placed in memory directly after the array of
pointers to HE*s. However, memory to hold it is not always allocated.
My assumption is that either
1: There's a code path that starts writing to the location it should be in,
without first calling realloc() to allocate memory for it.
2: There's an error in the code that works out the offset of the xpvhv_aux
structure given the pointer accessed via the macro HvARRAY()
but I can't find it by inspection, and I can't reproduce it, even by tweaking
the code to try to provoke the problem. Running regression tests under
valgrind doesn't find anything amiss either. I'm stuck. But I'm confident
that it's not a three-fold error in the calculation for the size of memory to
allocate for the array of HE **s.
I can only reproduce this on one instance of one test, but on that test
it can be reproduced every time.
Over-allocating the structure did make the problem go away, so there is
a clear relationship.
The condition where the corruption is detected has the characteristic
that the xhv_max = 7.
DBG exam hv-sv_any-xhv_max
HV\S_hv_auxinit\hv-sv_any-xhv_max:7
DBG exam hv-sv_u.svu_array
HV\S_hv_auxinit\hv-sv_u.svu_array: 0
The base of the allocated memory is below, by the old calculation a
malloc of 44 bytes.
HV\S_hv_auxinit\array: 10065784
The array will end up being stored at the address:
DBG eval/add hv-sv_u.svu_array
9964796
DBG exam hv-sv_u.svu_array
HV\S_hv_auxinit\hv-sv_u.svu_array: 10065784
The upper bound of memory is:
DBG eval 10065784+44
10065828
Which looks like it should be correct.
So I will undo my local change and see if I can capture some more data
corruptions to zero in on this.
Is there some quick way that I can turn on the DEBUG_m function once I
start reproducing the problem? It would be interesting to see if that
gave any more clues.
-John
[EMAIL PROTECTED]
Personal Opinion Only
