Re: [perl #37190] -DT -e 'use warnings;' crashes
On Sat, Sep 17, 2005 at 11:31:11AM -0700, Nicholas Clark wrote: Using -DT with use warnings; goes bang on OS X. I was able to get out of memory failures on FreeBSD, but everything works on x86/Linux, at least for me. I guess x86/Linux is just lucky - this seems to be a real bug, although quite where, I'm not sure. It looks like its crashing in code I wrote, so its probably my fault. If you don't mind waiting for a couple of weeks, I'll try to have a look somretime. -- Thank God I'm an atheist.
Re: Questions regarding Perl instrumentation
On Tue, Sep 13, 2005 at 11:14:07AM +0200, Rafael Garcia-Suarez wrote: Nicholas Clark wrote: From what I remember Alan telling me about what Dave had said, there are were a few more points other than entersub and leavesub that would need instrumentation. goto sub; was the most obscure, but I think that require was another. What about the unusual ways of exiting a subroutine, e.g. with next ? My suggestion to Alan was to hitch a ride on the PUSHSUB/POPSUB macros; that way you should be able to trap *all* occurances, including hand-rolled calls in XS (eg the call outs to Perl in List::Util) -- Emacs isn't a bad OS once you get used to it. It just lacks a decent editor.
Re: how to deal with static c++ object
On Tue, Sep 13, 2005 at 03:08:51PM +0800, Dongxu Ma wrote: In some case, a class will have a static object for special purpose. For instance: static foo foo::bar I want to port this object to perl by wrapping it as a sub like this: foo * foo::bar() CODE: RETVAL = (foo::bar); OUTPUT: RETVAL This will always cause a segfault while invoking the sub in perl script. Does anyone know the reason? You can't return a C++ object on the perl stack; perl wouldn't know what to do with it. How you get round this problems depends on what visibility you want the object to have within perl. If you just want to access the value of the object (eg if it just contains an integer value), then return an SV with user magic attached; the magic has a pointer to the static object, and the magic's get and set functions copy the integer value between the SV and the object. If you want to be able (at the perl level) to call methods on the object; then you need to return a Perl object, whose methods are written in XS. But anyway, this this is for discusiing the development of the perl interpreter, not for XS programming questions. -- Lady Nancy Astor: If you were my husband, I would flavour your coffee with poison. Churchill: Madam - if I were your husband, I would drink it.
Re: [perl #37134] Memory Leaking when joining threads?
On Sat, Sep 10, 2005 at 07:10:26PM -0700, Garry wrote:
I've attached a program that simulates the problem I'm experiencing.
Basically, as I spawn and join threads in a long
running program, I appear to leak away memory. The program shows how this
leak manifests itself. It shows the leak on version 5.8.6.
I can reduce the leak to this astonishingly small test case:
use threads;
sub ThreadRoutine {}
while (1) {
$thread = threads-new(\ThreadRoutine);
$thread-join;
}
This leaks like a sieve on 5.8.1+ and bleedperl (but not on 5.8.0 funnily
enough).
I haven't got time at the moment to investigate further (lots of other
things I should be doing).
--
Standards (n). Battle insignia or tribal totems.
Re: [perl #37128] undefing *foo{CODE} does not fully work
On Fri, Sep 09, 2005 at 06:11:49PM -0700, Ben Tilly wrote:
If you try to undef the CODE slot of a glob, it only halfway works.
ref(*foo{CODE}) will still show that it is a code reference, and
UNIVERSAL::can still shows that it is a code reference.
Undefing a sub is not the same as deleting a sub. Internally, the CV
continues to exist, but its pad and op tree are freed. cf:
$ perl587 -le 'my $x = []; undef @$x; print $x'
ARRAY(0x9c7d180)
$ perl587 -le 'my $x = sub {}; undef $x; print $x'
CODE(0x8e40bac)
In both cases the thing continues to exist, but has no useful 'value'.
--
My get-up-and-go just got up and went.
Re: [perl #37101] my $v if (0); leaves $v around
On Wed, Sep 07, 2005 at 05:19:55PM -0700, brucer @ gsg-lnx-bld1. cisco. com wrote: The following program invokes beta once instead of twice. Extremely non-intuitive. moving the #' down one line fixes it. 1) seems like it shouldn't compile. 2) $c is static and keeps its value between invocations if one instead of if (0) one has if ($b) This is boiled down from a real program, of course. This is a well-known problem, which is difficult to fix without breaking backwards compatibility (some people make use of the 'feature' to create static variables). The problem boils down to: If the 'my $x' is skipped at runtime, then at scope exit the variable isn't freed, meaning that on next scope entry the variable maintains its old value. -- Standards (n). Battle insignia or tribal totems.
Re: [perl #36733] %SIG not properly local-ized
On Sat, Sep 03, 2005 at 09:44:44PM -0700, Steve Peters via RT wrote:
I added Devel::Peek to see more of what's going on. I'm guessing the
copy during localization is not working correctly in this case. The
following chunk of code from mg.c may hold the key to the problem.
if ((mg-mg_flags MGf_COPY) vtbl-svt_copy) {
/* XXX calling the copy method is probably not correct. DAPM */
(void)CALL_FPTR(vtbl-svt_copy)(aTHX_ sv, mg, nsv,
mg-mg_ptr, mg-mg_len);
}
No, that's only where the magic type adds its own magic copy functions,
which %SIG doesn't. That only affects shared thread magic AFAIK, and I
plan to revisit it at some point.
--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
- Nicholas Clark, based on an original by Simon Cozens.
Re: [perl #36969] Syntax error crashing perl-5.8.6
On Sat, Aug 20, 2005 at 07:14:14PM -0700, lace @ jankratochvil. net wrote: #0 Perl_pad_free (my_perl=0x8390f10, po=29) at pad.c:1171 1171 SvPADTMP_off(PL_curpad[po]); (gdb) bt #0 Perl_pad_free (my_perl=0x8390f10, po=29) at pad.c:1171 #1 0x00e1fafa in Perl_op_clear (my_perl=0x8390f10, o=0x8878480) at op.c:516 #2 0x00e1fe49 in Perl_op_free (my_perl=0x8390f10, o=0x8878480) at op.c:380 #3 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88784a8) at op.c:368 #4 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88a7ac8) at op.c:368 #5 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88a7b10) at op.c:368 #6 0x00e1fe04 in Perl_op_free (my_perl=0x8390f10, o=0x88a7aa0) at op.c:368 #7 0x00e2daff in Perl_newATTRSUB (my_perl=0x8390f10, floor=293, o=0x88a74a0, proto=0x0, attrs=0x0, block=0x88a7aa0) Without looking at the original code, this looks a bit like a well-known problem that's fixed in 5.9.1. Are you able to try your code with 5.9.1 or 5.9.2 so that we can confirm whether it's the same problem? -- My Dad used to say 'always fight fire with fire', which is probably why he got thrown out of the fire brigade.
Re: [perl #37039] perlref documentation about optional - is too vague
On Sun, Sep 04, 2005 at 02:38:14AM -0700, Yitzchak Scott-Thoennes wrote:
On Thu, Sep 01, 2005 at 05:41:36PM -0700, Yitzchak Scott-Thoennes wrote:
BTW, cygwin only has bison 1.875b, not the allowed 1.875 or 1.875c,
but it seemed to work. I also note that Debian stable has 1.875d;
would it make sense to just allow any 1.875* version?
--- p/regen_perly.pl.orig 2005-05-07 04:36:14.0 -0700
+++ p/regen_perly.pl2005-08-31 11:16:02.86992 -0700
@@ -65,7 +65,7 @@
# the test below to allow that version too. DAPM Feb 04.
my $version = `$bison -V`;
-unless ($version =~ /\b(1\.875c?|2\.0)\b/) { die EOF; }
+unless ($version =~ /\b(1\.875[a-z]?|2\.0)\b/) { die EOF; }
You have the wrong version of bison in your path; currently 1.875
or 2.0 is required. Try installing
End of Patch.
Dave, any comment on this?
errr... applied as change #25353, thanks.
--
Justice is when you get what you deserve.
Law is when you get what you pay for.
Re: [perl #36969] Syntax error crashing perl-5.8.6
On Sun, Sep 04, 2005 at 06:41:20PM +0900, Jan Kratochvil wrote: Do you expect just replacing the binary CORE/libperl.so is possibly? Therefore - is this library binary compatible from 5.8.6 to 5.9.2 for all its libraries? I do not think so, so I will have to rebuild all the libraries. No, everything would have to be recompoiled from scratch. -- You never really learn to swear until you learn to drive.
Re: Fw: Tied hash numeric values are rounded off under Perl v5.8.6
On Thu, Sep 01, 2005 at 10:25:24PM +0200, Marcus Holland-Moritz wrote:
I think this is a bug in Perl itself that was introduced with
5.8.0 and is still present. It can be cut down to this code:
#!perl -wl
use Tie::Hash;
tie %h, Tie::StdHash;
$a = 3.55;
$_ = $a + 0;
$h{a} = $a;
print $h{a}, , , @h{qw(a)};
__END__
[EMAIL PROTECTED] ~ $ perl5.6.2 test.pl
3.55, 3.55
[EMAIL PROTECTED] ~ $ perl5.8.0 test.pl
3.55, 3
[EMAIL PROTECTED] ~ $ bleadperl test.pl
3.55, 3
It's down to the different ways Perl_sv_2pv_flags handles magic and
non-magic values. In the former case, it does mg_get(), which happens to set
the SV with NOK,pIOK,pNOK flags and IV = 3, NV = 3.55.
Then, the Cif (SvGMAGICAL(sv)) branch prefers I over N:
if (SvIOKp(sv)) {
goto tokensave;
}
if (SvNOKp(sv)) {
so stringifies to 3.
The non-magical branch only does the I thing if there isn't an N thing:
if (SvIOK(sv) || ((SvIOKp(sv) !SvNOKp(sv {
so it stringifies to 3.55.
I wouldn't really like to venture what the correct fix is, epecially as
I'm still consfused about the meanings of the public verses private N/I/P
flags.
--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has a go at making some friends of his own age for a
change.
-- Things That Never Happen in Star Trek #18
Re: ./perl -I lib -Dp -e '{package Dog}; my $spot = 0' 2 dogless
On Mon, Aug 22, 2005 at 03:15:59PM -0400, Rick Delaney wrote:
Here is some code I've used before with optimizer:
char* lexical_type(int pad_offset) {
SV* lexname;
lexname = *av_fetch(PL_comppad_name, pad_offset, TRUE);
if (!(SvFLAGS(lexname) SVpad_TYPED))
return NULL;
return HvNAME(SvSTASH(lexname));
}
or see PAD_COMPNAME_TYPE()
--
Never do today what you can put off till tomorrow.
Re: Data corruption - [EMAIL PROTECTED] - PERL_HV_ARRAY_ALLOC_BYTES?
On Sat, Aug 20, 2005 at 06:39:36PM +0100, Nicholas Clark wrote: Yes, good idea. You can do this by setting the bit values in $^D at runtime. So setting $^D to 128 just for the section you're interested in would be the same as -Dm on the command line, only locally. There's a table of letters and values in perlrun.pod. These days you can set $^D symbolicly too, eg $^D = 'm'; # same as -Dm -- Any [programming] language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. -- Larry Wall
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.
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: [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: resolving methods at compile time
On Thu, Aug 18, 2005 at 01:54:23PM -0500, David Nicol wrote: This would not work. The same sub entry op may call many different functions: $_-foo() for qw(A B C::D); Under discussion is optimizing in the case of typed localized variables. my dog $iggy; $iggy-make_sound; # bound early to dog::make_sound due to declared type not a general early binding. @Dog::ISA = qw(Mammal); ... my Mammal $x = new Dog; $x-foo(); # may be Dog::foo() or Mammal::foo() [unifying ops and SVs] would be a Dumb Thing. Do they have reference counts? I guess I can look at the source for once. BASEOP in op.h does not appear to define reference count field. Being able to recycle optree memory is another thing that would be more trouble than its worth. But repeated eval-strings isn't a memory leak --- how do we do that now? Mark and sweep? Return opnodes to a pool after an eval-string unless they get referred to by something external to the eval? ops are in a tree of ops that are attached to a CV. The head of the op tree has a refcnt, so that the tree can be shared amongst several CVs. When the last CV is freed, the tree is freed. Each OP struct is usually indivdually malloced or freed, although there is code, not normally enabled, to allocate them from arenas. This is of course irrelvant as to whether unifying OPs and SVs would be a good thing. -- In the 70's we wore flares because we didn't know any better. What possible excuse does the current generation have?
Re: resolving methods at compile time
On Wed, Aug 17, 2005 at 11:44:11AM -0700, Stas Bekman wrote: but what's the answer for my question? Does that declaration just gets ignored? A quick look at bleed src indicates that is only used to provide a stash name when calling attribute handlers, ie in my Stash $foo : attributes; -- Red sky at night - gerroff my land! Red sky at morning - gerroff my land! -- old farmers' sayings #14
Re: resolving methods at compile time
On Wed, Aug 17, 2005 at 03:37:13PM -0500, David Nicol wrote: which could also AIUI benefit /slightly/ from binding the subroutine's entry point directly to the node that calls it instead of looking the entry point up in a hash, This would not work. The same sub entry op may call many different functions: $_-foo() for qw(A B C::D); I am not certain how much the data structures that hold the optree and SVs have in common at this time, Absolutley nothing but I think unifying them would be a Good Thing No, it would be a Dumb Thing. -- O Unicef Clearasil! Gibberish and Drivel! - Bored of the Rings
Re: [PATCH] New test of IEEE floating point peculiarities
On Thu, Aug 11, 2005 at 03:57:27AM -0700, Yitzchak Scott-Thoennes wrote: Even worse: $ perl -we'$x = -.0; scalar(1.1 * $x); print $x' 0 'scuse my ignorance, but why is it important to preserve the sign on floating zeroes? -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
Re: [perl #36839] \xA0 (non-breaking space) does and doesn't matc h \s
On Tue, Aug 09, 2005 at 03:17:51PM +0400, Konovalov, Vadim wrote:
One need to use correct re-encoding functions or write \x{A0} instead of
\xA0
That shouldn't make any difference:
$ ./perl -Ilib -MDevel::Peek -e 'Dump \xA0'
SV = PV(0x985de28) at 0x985cce0
REFCNT = 1
FLAGS = (PADTMP,POK,READONLY,pPOK)
PV = 0x9864f80 \240\0
CUR = 1
LEN = 4
$ ./perl -Ilib -MDevel::Peek -e 'Dump \x{A0}'
SV = PV(0x9adce28) at 0x9adbce0
REFCNT = 1
FLAGS = (PADTMP,POK,READONLY,pPOK)
PV = 0x9ae3f80 \240\0
CUR = 1
LEN = 4
--
A major Starfleet emergency breaks out near the Enterprise, but
fortunately some other ships in the area are able to deal with it to
everyone's satisfaction.
-- Things That Never Happen in Star Trek #13
Re: Dtrace provider for perl?
On Fri, Aug 05, 2005 at 08:22:58PM +0100, Alan Burlison wrote: Do we actually have enough information to give the same sort of output as for PHP (i.e. function/file/line number) without building a debugging perl? yes. -- My get-up-and-go just got up and went.
Re: Dtrace provider for perl?
On Fri, Aug 05, 2005 at 08:32:43PM +0100, Alan Burlison wrote: That's the kind of answer I like ;-) Would you like me to elaborate? :-) -- In England there is a special word which means the last sunshine of the summer. That word is spring.
Re: Dtrace provider for perl?
On Fri, Aug 05, 2005 at 09:24:29PM +0100, Alan Burlison wrote: Hmm, having looked a the 165 lines of code needed to implement caller() I'm not sure that this is going to be lightweight enough to be practical. Caller is mostly doing hard stuff. A lot depends on the detail of when and how the dtrace stuff gets called, but: in principle, at the point a sub is called, the associated CV can be found using cv=find_runcv(); CvGV(cv) will then give the typeglob associated with it, and thus the name; the first op pointed to by CvSTART(cv) should be a control op, which will give you the filename and line number of the start of the function. The hard bit is getting the dtrace stuff called at the right point. Not knowing how dtrace works, I can't really comment further. -- Fire extinguisher (n) a device for holding open fire doors.
Re: Dtrace provider for perl?
On Fri, Aug 05, 2005 at 10:19:58PM +0100, Alan Burlison wrote: In the case of the PHP stuff I'd guess they are just passing the function name, filename and line number to dtrace at every function entry and exit. I guess we'd want to do the same - tracing each op dispatch would be way too expensive. If you're talking about producing a special perl binary that does this, it would be trivial - just a quick mod to pp_entersub. - wouldn't even need to call find_runcv, since entersub knws the CV its calling. Doing something via dynamically loadable XS would be harder - not sure how that could be done. -- Justice is when you get what you deserve. Law is when you get what you pay for.
Re: Dtrace provider for perl?
On Fri, Aug 05, 2005 at 10:57:11PM +0100, Alan Burlison wrote: Dave Mitchell wrote: If you're talking about producing a special perl binary that does this, it would be trivial - just a quick mod to pp_entersub. - wouldn't even need to call find_runcv, since entersub knws the CV its calling. And a corresponding mod to pp_leavesub I guess and pp_leavesubv? if you want to record leaving too, then you also need pp_return, pp_goto, *and* you need to handle all the cases of a non-normal exit from a sub, eg die trapped by eval, next LABEL where LABEL is outside the sub etc. This would be quite hard. Any suggestions for the best place to insert the trace call into pp_entersub? Somewhere around the 'now we have permission to enter the sub' comment? You're looking at 5.8.x code: in particular that comment is within a 5.005threads section that has been excised from bleed! In bleedperl, I'd suggest just before the RETURNOP(CvSTART(cv)); line. You'll also need to decide what to do when pp_enterusb is calling an XS sub; in this case there's no CvSTART(cv) op and so no way to deternine filename and line number (which makes sense, as there isn't a line number!). You also need to allow for perl -d, which causes pp_entersub to call DB::sub() each time rather than the real sub (it expects DB::Sub to call the real sub on your behalf) -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. -- Lady Croom - Arcadia
Re: Dtrace provider for perl?
On Sat, Aug 06, 2005 at 12:38:49AM +0100, Alan Burlison wrote:
Dave Mitchell wrote:
if you want to record leaving too, then you also need pp_return, pp_goto,
*and* you need to handle all the cases of a non-normal exit from a sub,
eg die trapped by eval, next LABEL where LABEL is outside the sub etc.
This would be quite hard.
Bah, there's always a catch. However 'hard' != 'impossible'. How easy
is it to get the same info on the sub name, file and line at the various
exit points?
You have to find all the places where perl pops the context stack (eg
Perl_dounwind() in pp_ctl.c), and each time it does a POPSUB(cx,sv), the
cx-blk_sub.cv field of the just-popped CX struct is the cv of the sub
being exited from.
Some subtle notes about popping the CX stack.
Some code just scans back through the context stack till it finds what
it's after (eg an eval block), and returns the index, *without* actually
popping anything, then later code actually does the popping.
macros like POPSUB don't actually decrement the context stack pointer;
they rely on something else to have already done it (eg POPBLOCK,
or an explicit cxstack_ix-- in the case of Perl_dounwind); all they
actually do is extract various values from the context block now perched
precariously one above the current stack top.
Perl actually has a stack of stacks. Whenever perl is about to do
something nasty (like call tie magic, or overload functions), it pushes a
new set of stacks, including a new context stack.
Some stack-unwinding functions (eg 'next LABEL_OUTSIDE_SUB') only scan
back through the current context stack; some (like eval/die) search back
through *all* context stacks.
Welcome to the whacky world of perl context!
I don't know exactly how the debugger works - does it eventually call
back into pp_entersub to dispatch the sub 'for real'?
No, it calls DB::sub() *instead* of the real sub, and sets $DB::sub to the
name of the sub which should be called. DB::sub() is then supposed to call
this sub on your behalf, and return any values; ie a minimal one would
look like
sub DB::sub { $DB::sub(@_) }
So the worst that will happen is that dtrace will show DB:sub being called
as well as the real sub
Thanks for all your help BTW :-)
No prob. Now, if only you could convince your superiors that my
consultancy fee is a twin-CPU V20z ;-)
--
Any [programming] language that doesn't occasionally surprise the
novice will pay for it by continually surprising the expert.
-- Larry Wall
Re: Dtrace provider for perl?
thinking further, your best strategy is probably to include the dtrace code in the PUSHSUB and POPSUB macros. -- This email is confidential, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have received this email in error, place it in its original wrapping and return for a full refund. By opening this email, you accept that Elvis lives.
Re: [PATCH] Re: [perl #36667] Lengthy parameter passed to eval leads to bus error on FreeBSD 5.4
On Thu, Aug 04, 2005 at 09:52:18PM +0200, Dominic Dunlop wrote:
Attached is a comprehensive but simple-minded patch that simply stops
Perl_peep from recursing to a depth a greater than 8192. When this
happens, you get a warning, and the code gets run unoptimized.
Perl_peep doesn't just do omptimisations; swome stuff is necessary for
normal running, eg
case OP_METHOD_NAMED:
/* Relocate sv to the pad for thread safety.
better approach would be to find out why the optimizer thinks it
needs such a large peephole in this case (more a picture window,
really) and persuade it to be less ambitious. But I don't understand
the optimizer at all -- hence the crude solution.
The optimiser processes ops in the order they're normally executed.
For stuff like boolean ops, there's a branch of code which isn't in the
'normal' execution path, eg
if (foo) { bar}
baz;
which is the same as
foo bar; baz;
the 'normal' path is foo - baz. So peep recurses down the 'other' branch
to make sure it gets processed too. However, when it follows the bar path,
the next op after bar is baz, so it continues its merry way into the next
statement. Eventually it finisheds returns, and the top-level peep
continues with the next op, baz, but finds it's already been processed,
and so quits.
The fix would probably be to temporary set the 'done' flag on the next op
before recursing. But I havn't got time to look into this yet.
--
I've often wanted to drown my troubles, but I can't get my wife to go
swimming.
Re: [perl #36667] Lengthy parameter passed to eval leads to bus error on FreeBSD 5.4
On Wed, Jul 27, 2005 at 08:21:01AM -0700, jnarron @ cdsinet. net wrote: I have test cases that I'm willing to send, but not attaching due to their sizes. Could you send them as a tar.gz attachment please? -- Thank God I'm an atheist.
Re: bareword test on ebcdic.
On Wed, Jul 27, 2005 at 11:01:08PM +0100, Nicholas Clark wrote: My question is, what are the bytes in UTF-EBCDIC that encode code point 3500? http://www.unicode.org/reports/tr16/ I *think* codepoint 3500, ie 0xdac, ie [0011][01101][01100] maps to the i8 bytes 1110[0011] 101[01101] 101[01100], ie 0xe3, 0xad, 0xac which after going through the i8 to UTF-EBCDIC byte conversion, comes out as 0xba, 0x54, 0x53 Obvious really. -- Thank God I'm an atheist.
Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Tue, Jul 26, 2005 at 01:06:27AM -0700, Michael G Schwern wrote: Good point. Originally that said unsuitable for encrypting so the explaination made a bit more sense. I'd assume crypt() is unsuitable for large amounts of text because the hash size is too small and there's a significant risk of collision, espcially if its DES. Anyone care to confirm? I think the docs should really say that this function's only purpose is for manipulating traditional UNIX-style password hashes, and that for any use not requiring backwards-compatibility, they should instead use something like Digest::MD5 (core) or Digest::SHA1 (non core). -- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff. -- Things That Never Happen in Star Trek #9
Re: gmake (perl-5.8.6) fails on z/OS
On Tue, Jul 26, 2005 at 03:29:43PM +0100, Nicholas Clark wrote: On Tue, Jul 26, 2005 at 07:22:55AM -0700, rajarshi das wrote: Hi, I made the following modifications to utf8.c : #ifdef EBCDIC uv = NATIVE_TO_UTF(uv); #endif Where in utf8.c? Your description of what you changed is inadequate for anyone else to understand the context of your change. I tried redoing it with a clean build, but it still fails. Why does configpm generate errors ? I don't know. I don't fully understand the workings of how perl's UTF-8 implementation is supposed to work on EBCDIC platforms. 1: Is that the only change you've made to the source code? 2: Without that change, how does your build fail? How do the errors differ? And some further questions: what exactly was the change you made? Did you wrap the existing uv = NATIVE_TO_UTF(uv) line with #ifdef, #endif; or did you add three extra lines somewhere, and if so, where? The usual way of providing this information is as the output of the diff command (if your system supports it), in fact preferably 'diff -u'. Why have you made this change? Did you read somewhere that it was necessary, and if so, where did you read this? (Url please.) If not, how did you come to the conclusion that the change was required? And what problem were you trying to fix? Dave -- Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 11:35:46PM +0200, Abigail wrote: On Tue, Jul 26, 2005 at 05:37:39PM +0100, Nicholas Clark wrote: So is wantarray's value is only specified within a subroutine or method which was called directly by other perl code true? No. $ perl -wle 'print eval wantarray' 1 $ No subroutine, no method. A quick look at the src shows that it scans back through the current context stack for an eval, sub or format. From this perspective, a require or do file is an eval. If it it fails to find one, it returns undef. It doesn't scan previous context stacks, so it wont backtrack through magic, tie, overload etc. -- The perl5 internals are a complete mess. It's like Jenga - to get the perl5 tower taller and do something new you select a block somewhere in the middle, with trepidation pull it out slowly, and then carefully balance it somewhere new, hoping the whole edifice won't collapse as a result. - Nicholas Clark, based on an original by Simon Cozens.
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 11:40:01PM +0100, Nicholas Clark wrote:
Would the core not being able to scan back past tie/overloading/magic/etc
be a bug that needs addressing?
I don't think so. Since the first thing that happens with tie, overload
etc is that it calls a sub, there will always be a sub context at the base
of the new context stack to be found. If it hasn't invoked a sub (eg
PERLSI_MAGIC), then it's hardly likely to be able to execute pp_wantarray.
Note that most context stack searching in Perl only searches the *current*
context stack, eg looking for labels with next or goto:
#!/usr/bin/perl
sub TIEARRAY { goto FOO }
my @a;
tie @a, 'main';
FOO:
$ perl587 /tmp/p
Can't find label FOO at /tmp/p line 3.
$
--
In my day, we used to edit the inodes by hand. With magnets.
Re: perlfunc sez crypt() encrypts... but it doesn't.
On Sat, Jul 23, 2005 at 01:08:49PM -0700, Michael G Schwern wrote: crypt() doesn't really encrypt, it hashes or digests. Yet perlfunc/crypt talks about encryption. This seems misleading. I discovered this while explaining that passwords aren't stored encrypted, they are hashed. This not-encryption is done with the crypt() function--erk. So I think it makes sense for the crypt docs to stop saying it encrypts. I'm no expert in cryptographic terminology, can anyone confirm or verify this? Well pedantically speaking, crypt() encrypts a block of zeros using a DES variation and the supplied password as a key, so yes it does encrypt; but yes, it's use is as as a secure hash, so maybe the description could do with some polishing. -- You never really learn to swear until you learn to drive.
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
On Thu, Jul 21, 2005 at 01:15:39PM -0700, Michael G Schwern wrote:
On Thu, Jul 21, 2005 at 10:20:22AM -0400, Shiping Zhang wrote:
But shouldn't the alias be to the elements of the list returned by sort,
not to the elements of the original list? Should sort sort a copy of its
argument and return the sorted copy?
That's what I'm thinking, that this is a sort/foreach optimization gone
wrong. foreach $_ works on aliases of the array its looping over but sort
does NOT sort in place. foreach (sort @a) should not loop over aliases
to @a any more than foreach (map {$_} @a) should.
I wouldn't expect map to maintain the alias, because map returns the
result of an expression; on the other hand, grep, like sort, returns the
original values, and like sort, it maintains the alias:
$ perl587 -we '@a=qw(1 2 3); for (grep /\d/, @a) { $_++ } print @a\n'
2 3 4
$
I don't think its a bug so much as undocumented behaviour. fixing it
would involve doing a whole bunch of unneccessary copying in sort and
grep.
--
SCO - a train crash in slow motion
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
On Thu, Jul 21, 2005 at 04:22:19PM -0500, Graham Barr wrote: I don't think its a bug so much as undocumented behaviour. fixing it would involve doing a whole bunch of unneccessary copying in sort and grep. And reverse and any XS sub that directly returns any of its SV arguments (eg List::Util::shuffle), not to mention any sub that returns a slice of @_ Er, not the last one. subroutine returns make copies of the list -- Monto Blanco... scorchio!
Re: [PATCH] More embed.fnc notes, with new known errors!
On Thu, Jul 21, 2005 at 04:06:49PM -0500, Andy Lester wrote: The functions that I broke are Perl_sv_vcatpvfn and Perl_sv_vsetpvfn. The SV **svargs parm now has a NN on it, meaning GCC will squawk at compile if a null is passed in, because the code refers to *args, which would be a NULL deref if args is NULL. However, util.c has code that passes in hardcoded NULLs. :-( My reading of the Perl_sv_vcatpvfn documenttaion (and reading of the code) is that it's perfectly legit to pass a null svargs: one of other of args or svargs should contain a value, but not both. Also, all *args derefs are protected by an if(args). Dave. -- There's a traditional definition of a shyster: a lawyer who, when the law is against him, pounds on the facts; when the facts are against him, pounds on the law; and when both the facts and the law are against him, pounds on the table. -- Eben Moglen referring to SCO
Re: [PATCH] More embed.fnc notes, with new known errors!
On Thu, Jul 21, 2005 at 05:18:01PM -0500, Andy Lester wrote: On Thu, Jul 21, 2005 at 11:10:51PM +0100, Dave Mitchell ([EMAIL PROTECTED]) wrote: My reading of the Perl_sv_vcatpvfn documenttaion (and reading of the code) is that it's perfectly legit to pass a null svargs: one of other of args or svargs should contain a value, but not both. Also, all *args derefs are protected by an if(args). But not svargs. See the line with sv_catsv(sv, *svargs); Yes, but it's still perfectly legal and ok to pass a hardcoded Null as the svargs param (as long as args isn't also null), so delaring svargs as NN is wrong. -- This is a great day for France! -- Nixon at Charles De Gaulle's funeral
Re: [perl #969] shifting of bitvecs considered broken
On Wed, Jul 20, 2005 at 05:56:12AM -0700, Steve Peters via RT wrote: Resubmitting a bug report of mine back from February; this time through the proper channel (perlbug, not p5p). [paste] While editing my Damn Book I re-remembered that couple of months back I ran into an anomaly in the handling of bitvectors. Fiction: you have a bitvector which you want to shift. The current (5.005_03-MT5) fact: perl -wle '$b = ; vec($b, 0, 1) = 1;print unpack(b*, $b);$b=1;print unpack(b*, $b)' 1000 1100 Huh? Adding -w tells more, as usual: Argument ^A isn't numeric in left_shift at -e line 1. So left_shift assumes that the argument to shift is a number, but ^A isn't, so it gets converted to string zero 0 (48, 0x30, 0b110). I consider this behaviour to be rather broken. I think $b = 1 should shift the whole bitvector left by one position and vec($b, 2, 8) = 2 should shift the bits 16..23 right by two positions (of course not leaking into bits 8..15). Just so we're clear, and to add a proper TODO test case, what would you consider the proper output to be? I am opposed to such a change in behaviour. = operates on numeric values, while vec operates on strings. vec($b,0,1) = 1 is just the same as $b = \x0\x0\x0\x01 (ignoring endianess and int size complications) If the and operators were to take any string as a bit pattern, then it would break code like: $b=1; $b = 2; print $b which should print 4, not \xc4. -- The Enterprise is captured by a vastly superior alien intelligence which does not put them on trial. -- Things That Never Happen in Star Trek #10
Re: [perl #34524] sv_rvweaken (Scalar::Util::weaken) is inneffective on tied variables
On Mon, Mar 21, 2005 at 08:42:11PM -, philippe. cote @ usherbrooke. ca
wrote:
sv_rvweaken doesn't handle tied variables
Proof :
+-+
Sample code
+-+
#!/usr/bin/perl
use strict;
use warnings;
use Util::Monitor;
use Scalar::Util qw(weaken);
use Devel::Peek;
{
my (@a);
$a[0] = [EMAIL PROTECTED];
#tie @a, 'TestArray';
Dump($a[0],1);
weaken($a[0]);
Dump($a[0],1);
print Leaving scope\n;
}
print Scope left\n;
package TestArray;
use Tie::Array;
use base 'Tie::StdArray';
sub DESTROY { print Monitor::TestArray::DESTROY : $_[0]\n; }
I'm not really sure what you expect the effect of weakening a tied array
element should be. I suspect that in the general case doing this makes no
sense.
1;
+-+
Output without tie @a, 'TestArray'
(Just to show you that weaken works without the tie)
+-+
SV = RV(0x81829c0) at 0x814127c
REFCNT = 1
FLAGS = (ROK)
RV = 0x814e740
SV = PVAV(0x81426cc) at 0x814e740
REFCNT = 2
FLAGS = (PADBUSY,PADMY)
IV = 0
NV = 0
ARRAY = 0x814
FILL = 0
MAX = 3
ARYLEN = 0x0
FLAGS = (REAL)
SV = RV(0x81829c0) at 0x814127c
REFCNT = 1
FLAGS = (ROK,WEAKREF,IsUV)
RV = 0x814e740
SV = PVAV(0x81426cc) at 0x814e740
REFCNT = 1
FLAGS = (PADBUSY,PADMY,RMG)
IV = 0
NV = 0
MAGIC = 0x8266f08
MG_VIRTUAL = PL_vtbl_backref
MG_TYPE = PERL_MAGIC_backref()
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x81411c8
SV = PVAV(0x8263704) at 0x81411c8
REFCNT = 2
FLAGS = ()
IV = 0
NV = 0
ARRAY = 0x82677e8
FILL = 0
MAX = 3
ARYLEN = 0x0
FLAGS = (REAL)
ARRAY = 0x814
FILL = 0
MAX = 3
ARYLEN = 0x0
FLAGS = (REAL)
Leaving scope
Scope left
+-+
Output with tie @a, 'TestArray';
+-+
SV = PVLV(0x817c568) at 0x81413f0
REFCNT = 1
FLAGS = (TEMP,GMG,SMG,RMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x81505b8
MG_VIRTUAL = PL_vtbl_packelem
MG_TYPE = PERL_MAGIC_tiedelem(p)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x814139c
SV = RV(0x81829ac) at 0x814139c
REFCNT = 2
FLAGS = (ROK)
RV = 0x8141354
TYPE = t
TARGOFF = 0
TARGLEN = 0
TARG = 0x81413f0
SV = PVLV(0x817c568) at 0x81413f0
REFCNT = 1
FLAGS = (TEMP,GMG,SMG,RMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x81505b8
MG_VIRTUAL = PL_vtbl_packelem
MG_TYPE = PERL_MAGIC_tiedelem(p)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x814139c
SV = RV(0x81829ac) at 0x814139c
REFCNT = 2
FLAGS = (ROK)
RV = 0x8141354
TYPE = t
TARGOFF = 0
TARGLEN = 0
TARG = 0x81413f0
Leaving scope
Scope left
Monitor::TestArray::DESTROY : TestArray=ARRAY(0x8141354)
+-+
Explanations
+-+
We see that weaken is not applied on a tied variable. I've been
searching in source code and calls goes like this :
Scalar::Util::weaken - sv_rvweaken - Perl_sv_rvweaken
+-+
Scalar::Util::weaken source code
+-+
void
weaken(sv)
SV *sv
PROTOTYPE: $
CODE:
#ifdef SvWEAKREF
sv_rvweaken(sv);
#else
croak(weak references are not implemented in this release of perl);
#endif
We see clearly that it only calls sv_rvweaken from the perl source code.
So this method doesn't contain bugs.
We also finds that sv_rvweaken is associated to Perl_sv_rvweaken as
defined by embed.h
Let's look at this code
+-+
Perl_sv_rvweaken source code from sv.c
+-+
/*
=for apidoc sv_rvweaken
Weaken a reference: set the CSvWEAKREF flag on this RV; give the
referred-to SV CPERL_MAGIC_backref magic if it hasn't already; and
push a back-reference to this RV onto the array of backreferences
associated with that magic.
=cut
*/
SV *
Perl_sv_rvweaken(pTHX_ SV *sv)
{
SV *tsv;
if (!SvOK(sv)) /* let undefs pass */
return sv;
if (!SvROK(sv))
Perl_croak(aTHX_ Can't weaken a nonreference);
else if (SvWEAKREF(sv)) {
Re: ithreads: CLONE is not invoked on returned values from join
On Sun, Mar 27, 2005 at 06:31:59PM -0500, Stas Bekman wrote:
So we have CLONE that allows us to properly clone objects when a new
thread is started. The current invocation approach really sucks, since
trying to figure out what things need to be cloned is a pain-in-a-back.
But it's doable [1]. Previously we have started discussing of passing the
objects to be cloned as an argument(s) to CLONE, but it didn't get anywhere.
Now I've discovered a new problem. If intentially or accidently you have
to return an object from a thread callback:
threads-new(\read_test)-join;
sub read_test {
my $obj = Foo-new;
#1;
}
You're screwed since now you have a dangling temp object which you didn't
really want to in first place (but can be figured out by reading the
manpage), but the real problem is that even if you did want it:
my $ret_obj = threads-new(\read_test)-join;
this object is not properly cloned. If you had a C pointer stashed in
SvIVX and you have a DESTROY method that frees that pointer, it's a sure
segfault, since both the parent thread and the child thread will point to
the same C struct.
So I'd love to see at least perl 5.10 dealing with this properly (of
course 5.8.x would be lovely too). The wishlist:
1) have CLONE get the SVs to clone as arguments to it, which will
tremendously simplify the life of developers.
2) fix the explained above bug and run the objects through CLONE when they
are returned from join().
How does this interact with the new CLONE_SKIP thinggy?
--
Spock (or Data) is fired from his high-ranking position for not being able
to understand the most basic nuances of about one in three sentences that
anyone says to him.
-- Things That Never Happen in Star Trek #19
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: [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.
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: [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: [perl #35847] File::Find not performing as documented
On Mon, Jul 11, 2005 at 12:35:36AM -0700, Michael G Schwern wrote:
I still can't reproduce this on OS X.
I guess the filesystem you have doesn't have the nlinks 2 property
On Sun, Jul 10, 2005 at 07:31:02PM +0100, Dave Mitchell wrote:
So we either fix the docs, as suggested, or fix the code to stat *every*
entry before calling the wanted function. The latter would defeat the
purpose of the optimisation, so I vote for the former.
I'd be interested to see, given how much work File::Find does anyway,
just how much a performance hit fixing this would be.
It makes a huge difference on my laptop (slow disk):
use File::Find;
$File::Find::dont_use_nlink = $ARGV[0];
my $count=0;
find(sub { $count++ }, '/usr');
print count=$count\n;
running this the first time with arg0 = 0 took about 3 minutes; rerunning
it takes about 10 secs because all the directory reads are cached by the
OS.
Susequently running with arg0 = 1 (bearing in mind that the directories
are still cached) takes about 6 minutes on both the first and subsequent
runs, presumably because my laptop hasn't got enough free ram to cache
all 300K inodes that have to be read under /usr.
CPU usage is almost zero; the code is completely IO bound.
Perhaps the best approrach would be to document that an lstat is no longer
guaranteed, but add a new option to the find() options hash, 'lstat',
that if true, reinstates the guarantee.
--
Now is the discount of our winter tent
-- sign seen outside camping shop
Re: [perl #17765] UTF-8 in the debugger
On Tue, Jul 12, 2005 at 04:13:29PM -0700, Michael G Schwern via RT wrote:
[joemcmahon - Fri Jun 03 15:00:45 2005]:
Same program in the debugger:
% perl -de '
$_ = \x{100};
s/[\x{100}]/o/;
print $_\n;
'
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:2): $_ = \x{100};
DB1 c
Wide character in print at -e line 4.
?
This seems to fix the problem; it just adds :utf8 to the debugger's
output filehandle.
The problem is not the wide character in print warning. The problem
is that $_ is not 'o' as it is when run outside the debugger.
Seems to be fixed in 5.8.7 and bleed.
--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
-- Things That Never Happen in Star Trek #10
Re: Text::Balanced patches
On Wed, Jun 30, 2004 at 06:00:03PM +0100, Steve Hay wrote: Looking at closing a few more perlbugs, I notice that David Manura submitted 5 patches for Text-Balanced back in January (all with new test cases): perlbugs 25151, 25154, 25156, 25157 and 25158. In 25157, Dave Mitchell requested that they all be resent as one jumbo patch, which David Manura kindly did. Is there any particular reason that this jumbo patch was never applied? (just for the record, seeing as you've applied it now anyway) I don't think there was any particular reason; it just got forgotten amongst the other 2698 messages currently in my p5p folder :-( -- This is a great day for France! -- Nixon at Charles De Gaulle's funeral
Re: [perl #9012] Segfault with -DXst
On Wed, Jul 13, 2005 at 07:31:36AM -0700, Steve Peters via RT wrote:
This program displays a severe memory leak:
$x = 0123456789;
for (1..10) {
my @s;
$x =~ /.*(.+?)(?{push @s, $1})(?!)/;
}
END { print STDERR Global destruction\n }
(Probably related to the bug report I just filed.)
While investigating it, I ran:
/src/bleadperl-build/perl -DXst /tmp/mem.pl
Perl died from a segmentation fault partway through the run. However,
[snip]
This core dump is still around in [EMAIL PROTECTED] Below is the backtrace.
yep, this comes under the category of re_eval isn't safe accessing outer
lexical vars. Yes another problem that will vanish when I finish my my
mythical rewrite of the re_eval code.
--
The optimist believes that he lives in the best of all possible worlds.
As does the pessimist.
Re: demacroize ckWARN*
On Wed, Jul 13, 2005 at 03:50:47PM +0100, [EMAIL PROTECTED] wrote: Dave Mitchell [EMAIL PROTECTED] wrote: :On Sat, Jul 02, 2005 at 04:53:35PM +0100, Dave Mitchell wrote: : On Sat, Jul 02, 2005 at 04:52:43PM +0100, [EMAIL PROTECTED] wrote: : If I remember right, a lot of code tests whether the warning is enabled : before testing whether the warning case applies, on the assumption that : the first check is quick. Many of those cases may want to be re-evaluated : in the light of this patch. : : I was going to save that for another day :-) : :That day has now arrived: The tipping point has moved less far than this patch implies: the new ckWARN() function still takes pretty tightly bounded time, and should be preferred over some of the less tightly bounded calls such as strchr(). Guessing (mostly), I think it should come before the function call in: doio.c chunks #1, #3 pp_hot.c chunk #2 toke.c chunks #3, #4 I don't think it really makes that much difference, since the ckWARN is usually true and the strchr usually fails, but I've fixed up the chunks you suggested anyway. Looking through the patch also suggests that the handling of Unicode strings in general may be getting slowed down a lot by all the warnings checks: as written, they're required to pass the right flags to the low-level functions, but it might be possible to refactor the later towards some new functions that would be able to defer the check until a warnable condition were encountered. I tried to do some basic factoring out as I went along, but something more heavyweight probably needs doing too. Ironically, the low-level functions themsleves also do a ckWARN, so some refactoring is definitely in order. I'll probably have a look at this at the same time as I get round to fixing the $latin1 =~ /$utf8/i bug. -- That he said that that that that is is is debatable, is debatable.
Re: [perl #36521] perlbug AutoReply: Deep recursion on subroutine CGI::Carp::warn
On Wed, Jul 13, 2005 at 01:40:03PM -0700, Michael G Schwern wrote:
The problem is the use of goto foo inside a __WARN__ when foo also calls
warn(). I suspect whatever magic that keeps warn() from calling
$SIG{__WARN__} when its already inside one is lost.
#!/sw/bin/perl -w
my $warn = sub { warn(join \n, caller, @_) };
$SIG{__WARN__} = sub {
# $warn; # this is ok
goto $warn; # this segfaults
};
warn foo;
the disabling of $SIG{__WARN__} was done by cheking the call depth of the
associated sub. The goto foo ensured that this was always at zero.
The change below fixes this by localsised PL_warnhook t6o zero within a
call to a warn hook.
--
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
Change 25160 by [EMAIL PROTECTED] on 2005/07/17 20:12:54
$SIG{__WARN__} = sub { goto foo } could recurse infinitely
Affected files ...
... //depot/perl/t/op/goto.t#30 edit
... //depot/perl/util.c#484 edit
Differences ...
//depot/perl/t/op/goto.t#30 (xtext)
@@ -10,7 +10,7 @@
use warnings;
use strict;
-plan tests = 56;
+plan tests = 57;
our $foo;
while ($?) {
@@ -436,3 +436,13 @@
like($@, qr/Can't goto subroutine from an eval-string/, 'eval string');
eval { goto null };
like($@, qr/Can't goto subroutine from an eval-block/, 'eval block');
+
+# [perl #36521] goto foo in warn handler could defeat recursion avoider
+
+{
+my $r = runperl(
+ stderr = 1,
+ prog = 'my $d; my $w = sub { return if $d++; warn q(bar)};
local $SIG{__WARN__} = sub { goto $w; }; warn q(foo);'
+);
+like($r, qr/bar/, goto foo in warn);
+}
//depot/perl/util.c#484 (text)
@@ -1278,6 +1278,8 @@
SV *msg;
ENTER;
+ SAVESPTR(PL_warnhook);
+ PL_warnhook = Nullsv;
save_re_context();
msg = newSVpvn(message, msglen);
SvFLAGS(msg) |= utf8;
Re: [perl #9720] threads::shared and perlthrtut: Update to give example of object
On Thu, Jul 14, 2005 at 01:33:54AM -0700, Michael G Schwern via RT wrote:
[EMAIL PROTECTED] - Sun Jun 23 02:21:24 2002]:
Having tried to share objects by writing stuff along the lines:
my $a : shared = new FOOBAR;
It took a posting to comp.lang.perl.misc before I realised the error
of my ways:
my $a = new FOOBAR;
share($a);
I don't think the threads::shared and perlthrtut docs make this clear
enough -
folks coming to ithreads from Java etc are going to finds things a bit
odd to
begin with.
SOLUTION: More examples in the docs please, esp. regarding object
sharing. Also
maybe trim down some of the general threading info in perlthrtut with
more
focus on perl threads and how to use them idiomatically.
threads::shared and perlthrtut still lacks this additional documentation.
How about this:
--
The greatest achievement of the Austrians has been convincing the world
that Hitler was German, and Mozart Austrian.
Change 25161 by [EMAIL PROTECTED] on 2005/07/17 20:54:15
[perl #9720] document what can be assigned to a shared scalar
Affected files ...
... //depot/perl/ext/threads/shared/shared.pm#38 edit
Differences ...
//depot/perl/ext/threads/shared/shared.pm#38 (text)
@@ -53,6 +53,10 @@
use threads::shared;
my $var : shared;
+ $var = $scalar_value;
+ $var = $shared_ref_value;
+ $var = share($simple_unshared_ref_value);
+ $var = share(new Foo);
my($scalar, @array, %hash);
share($scalar);
@@ -101,6 +105,9 @@
Cshare will traverse up references exactly Ione level.
Cshare(\$a) is equivalent to Cshare($a), while Cshare(\\$a) is not.
+This means that you must create nested shared data structures by first
+creating individual shared leaf notes, then adding them to a shared hash
+or array.
A variable can also be marked as shared at compile time by using the
Cshared attribute: Cmy $var : shared.
@@ -109,6 +116,20 @@
need to use Cshare([]) and Cshare({}) syntax due to problems
with Perl's prototyping.
+The only values that can be assigned to a shared scalar are other scalar
+values, or shared refs, eg
+
+my $var : shared;
+$var = 1; # ok
+$var = share([]); # ok
+$var = []; # error
+$var = A-new; # error
+$var = share(A-new); # ok as long as the A object is not nested
+
+Note that it is often not wise to share an object unless the class itself
+has been written to support sharing; for example, an object's destructor
+may get called multiple times, one for each thread's scope exit.
+
=item lock VARIABLE
Clock places a lock on a variable until the lock goes out of scope.
Re: Typo in t/op/stat.t
On Fri, Jul 15, 2005 at 02:05:44AM -0700, Gisle Aas wrote:
Found yet another strangeness in that file. chown() is called with the
filename as the second argument, but the second argument is supposed
to be the gid. It means that the chown() call in stat.t has always
been a noop. This patch make the chown functional, but I still don't
think it does anything useful. Anybody have an idea of what this line
was supposed to achieve?
No idea; but I've decided to just delete it (change 25162) rather than
fixing it.
--- t/op/stat.t.orig 2005-07-15 01:57:40.0 -0700
+++ t/op/stat.t 2005-07-15 01:58:10.0 -0700
@@ -171,7 +171,7 @@
# in ms windows, $tmpfile inherits owner uid from directory
# not sure about os/2, but chown is harmless anyway
-eval { chown $,$tmpfile; 1 } or print # $@ ;
+eval { chown $,$),$tmpfile; 1 } or print # $@ ;
ok(chmod(0700,$tmpfile),'chmod 0700');
ok(-r $tmpfile, ' -r');
--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
-- Bill Royston
Re: [perl #36521] perlbug AutoReply: Deep recursion on subroutine CGI::Carp::warn
On Sun, Jul 17, 2005 at 02:27:35PM -0700, Michael G Schwern wrote:
On Sun, Jul 17, 2005 at 09:41:58PM +0100, Dave Mitchell wrote:
+# [perl #36521] goto foo in warn handler could defeat recursion avoider
+
+{
+my $r = runperl(
+ stderr = 1,
+ prog = 'my $d; my $w = sub { return if $d++; warn q(bar)};
local $SIG{__WARN__} = sub { goto $w; }; warn q(foo);'
+);
+like($r, qr/bar/, goto foo in warn);
This program does not segfault, it does nothing.
0 ~$ perl5.8.6 -wle 'my $d; my $w = sub { return if $d++; warn q(bar)}; local
$SIG{__WARN__} = sub { goto $w; }; warn q(foo);'
0 ~$
That's the idea. In fixed bleed, it prints a warning:
$ ./perl -wle 'my $d; my $w = sub { return if $d++; warn q(bar)}; local
$SIG{__WARN__} = sub { goto $w; }; warn q(foo);'
bar at -e line 1.
$
The test minimally detects bad behaviour while avoiding runaway recursion
and segfault.
--
Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor.
Re: [perl #36521] perlbug AutoReply: Deep recursion on subroutine CGI::Carp::warn
On Sun, Jul 17, 2005 at 04:25:19PM -0700, Michael G Schwern wrote: On Mon, Jul 18, 2005 at 12:07:23AM +0100, Dave Mitchell wrote: But with runperl() its ok to segfault, its run in a different process. I know. Orignally I was trying to write the test to run in the same process (thus the need to avoid segfault), but couldn't get round the fact that when working correctly, it needed to write to STDERR, which is why I then bunged it in a freshperl. You can even reduce it using fresh_perl_like(). Ooh, I'll try to remember that in future. -- SCO - a train crash in slow motion
Re: [perl #7565] Thread safe queues on SMP kernel
On Thu, Jul 14, 2005 at 01:24:22AM -0700, Michael G Schwern via RT wrote: When run using 5.8.6 and ithreads perl thinks for a while and then sez: $ perl ~/tmp/test A thread exited while 4 threads were running. So this looks like an issue in Thread::Queue and not 5.005threads. Unless the sample code is not sane, but I don't know threads well enough to evaluate that. Changing the code to 'use threads' from 'use Thread' (and minor fixups as a consequence of that) and it works fine. So I presume its a problem in the old Threads.pm acting as a compatibility layer for ithreads. -- In England there is a special word which means the last sunshine of the summer. That word is spring.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Mon, Jul 11, 2005 at 01:29:37PM +0100, Steve Hay wrote: The patch below fixes it, and all tests still pass. Is it OK? looks good to me -- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff. -- Things That Never Happen in Star Trek #9
Re: demacroize ckWARN*
On Sat, Jul 02, 2005 at 04:53:35PM +0100, Dave Mitchell wrote:
On Sat, Jul 02, 2005 at 04:52:43PM +0100, [EMAIL PROTECTED] wrote:
If I remember right, a lot of code tests whether the warning is enabled
before testing whether the warning case applies, on the assumption that
the first check is quick. Many of those cases may want to be re-evaluated
in the light of this patch.
I was going to save that for another day :-)
That day has now arrived:
--
There's a traditional definition of a shyster: a lawyer who, when the law
is against him, pounds on the facts; when the facts are against him,
pounds on the law; and when both the facts and the law are against him,
pounds on the table.
-- Eben Moglen referring to SCO
Change 25129 by [EMAIL PROTECTED] on 2005/07/13 00:21:13
make the expensive ckWARN() be called as late as possible
reorganise
if (ckWARN(FOO) should_not_happen_condition)
to
if (should_not_happen_condition ckWARN(FOO))
Affected files ...
... //depot/perl/doio.c#274 edit
... //depot/perl/gv.c#258 edit
... //depot/perl/op.c#696 edit
... //depot/perl/pad.c#64 edit
... //depot/perl/perlio.c#279 edit
... //depot/perl/pp.c#473 edit
... //depot/perl/pp_hot.c#410 edit
... //depot/perl/pp_pack.c#104 edit
... //depot/perl/pp_sys.c#431 edit
... //depot/perl/regcomp.c#380 edit
... //depot/perl/regexec.c#357 edit
... //depot/perl/sv.c#955 edit
... //depot/perl/toke.c#580 edit
Differences ...
//depot/perl/doio.c#274 (text)
@@ -566,7 +566,9 @@
}
}
if (!fp) {
- if (ckWARN(WARN_NEWLINE) IoTYPE(io) == IoTYPE_RDONLY strchr(name,
'\n'))
+ if (IoTYPE(io) == IoTYPE_RDONLY strchr(name, '\n')
+ckWARN(WARN_NEWLINE)
+ )
Perl_warner(aTHX_ packWARN(WARN_NEWLINE), PL_warn_nl, open);
goto say_false;
}
@@ -1079,7 +1081,7 @@
if (!io)
return TRUE;
-else if (ckWARN(WARN_IO) (IoTYPE(io) == IoTYPE_WRONLY))
+else if ((IoTYPE(io) == IoTYPE_WRONLY) ckWARN(WARN_IO))
report_evil_fh(gv, io, OP_phoney_OUTPUT_ONLY);
while (IoIFP(io)) {
@@ -1392,7 +1394,7 @@
s = SvPVX_const(PL_statname); /* s now NUL-terminated */
PL_laststype = OP_STAT;
PL_laststatval = PerlLIO_stat(s, PL_statcache);
- if (PL_laststatval 0 ckWARN(WARN_NEWLINE) strchr(s, '\n'))
+ if (PL_laststatval 0 strchr(s, '\n') ckWARN(WARN_NEWLINE))
Perl_warner(aTHX_ packWARN(WARN_NEWLINE), PL_warn_nl, stat);
return PL_laststatval;
}
@@ -1418,8 +1420,8 @@
return (PL_laststatval = -1);
}
}
-else if (ckWARN(WARN_IO) PL_laststype != OP_LSTAT
-(PL_op-op_private OPpFT_STACKED))
+else if (PL_laststype != OP_LSTAT
+(PL_op-op_private OPpFT_STACKED) ckWARN(WARN_IO))
Perl_croak(aTHX_ no_prev_lstat);
PL_laststype = OP_LSTAT;
//depot/perl/gv.c#258 (text)
@@ -547,8 +547,9 @@
/*
* Inheriting AUTOLOAD for non-methods works ... for now.
*/
-if (ckWARN2(WARN_DEPRECATED, WARN_SYNTAX) !method
- (GvCVGEN(gv) || GvSTASH(gv) != stash))
+if (!method (GvCVGEN(gv) || GvSTASH(gv) != stash)
+ckWARN2(WARN_DEPRECATED, WARN_SYNTAX)
+)
Perl_warner(aTHX_ packWARN2(WARN_DEPRECATED, WARN_SYNTAX),
Use of inherited AUTOLOAD for non-method %s::%.*s() is deprecated,
packname, (int)len, name);
//depot/perl/op.c#696 (text)
@@ -1767,11 +1767,12 @@
OP *o;
bool ismatchop = 0;
-if (ckWARN(WARN_MISC)
- (left-op_type == OP_RV2AV ||
+if ( (left-op_type == OP_RV2AV ||
left-op_type == OP_RV2HV ||
left-op_type == OP_PADAV ||
- left-op_type == OP_PADHV)) {
+ left-op_type == OP_PADHV)
+ckWARN(WARN_MISC))
+{
const char *desc = PL_op_desc[(right-op_type == OP_SUBST ||
right-op_type == OP_TRANS)
? right-op_type : OP_MATCH];
@@ -1960,8 +1961,8 @@
;
#endif
else {
- if (ckWARN(WARN_PARENTHESIS)
-PL_bufptr PL_oldbufptr PL_bufptr[-1] == ',')
+ if ( PL_bufptr PL_oldbufptr PL_bufptr[-1] == ','
+ckWARN(WARN_PARENTHESIS))
{
char *s = PL_bufptr;
bool sigil = FALSE;
@@ -3528,7 +3529,7 @@
if (first-op_type == OP_CONST) {
if (first-op_private OPpCONST_STRICT)
no_bareword_allowed(first);
- else if (ckWARN(WARN_BAREWORD) (first-op_private OPpCONST_BARE))
+ else if ((first-op_private OPpCONST_BARE) ckWARN(WARN_BAREWORD))
Perl_warner(aTHX_ packWARN(WARN_BAREWORD), Bareword found in
conditional);
if ((type == OP_AND SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_OR !SvTRUE(((SVOP*)first)-op_sv)) ||
@@ -3564,8 +3565,8 @@
return first;
}
}
-else if (ckWARN(WARN_MISC) (first-op_flags OPf_KIDS
Re: [PATCH] yet another way of debugging memory allocations
On Sun, Jul 10, 2005 at 01:03:10PM +0300, Jarkko Hietaniemi wrote: The attached small patch is poor man's valgrind: it injects a dose of logging into Newx() et alia so that if PERL_MEM_LOG is defined in compile-time, all Newx() et alia calls go through logging functions, which most importantly pass in the source code file and linenumber. Thanks, applied as change #25105 -- You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad. -- Monty Python - Finland
Re: [perl #17650] [PATCH] DESTROY can prevent propagation of die
On Fri, Jul 08, 2005 at 03:59:34PM -0400, Alex Vandiver wrote: Heya, I got bitten by this bug today. I'm not altogether satisfied by the last and only comment on the bug, which summarizes to but there's a workaround, so it's not perl's fault! Attached is a patch which restores $@ after any DESTROY blocks have 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. -- There's a traditional definition of a shyster: a lawyer who, when the law is against him, pounds on the facts; when the facts are against him, pounds on the law; and when both the facts and the law are against him, pounds on the table. -- Eben Moglen referring to SCO
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
On Fri, Jul 08, 2005 at 09:45:32AM +0300, Jarkko Hietaniemi wrote: I won't have time to look into this anytime soon, but I think the fix for the second case shouldn't be too hard to find. First of all, if either the matcher or the matchee are UTF-8, we should never ever ever end up calling the bare ibcmp(), but instead ibcmp_utf8() with the right combination of flags to indicate which or both is UTF-8. if ibcmp is replaced with ibcmp_utf8, what should ibcmp_locale be replaced with? -- The Enterprise is captured by a vastly superior alien intelligence which does not put them on trial. -- Things That Never Happen in Star Trek #10
Re: problem building latest perl (24978) on win32
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, linking in an old private copy rather than using the OS's version, doesn't sound like the best of policies -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
On Fri, Jul 08, 2005 at 05:07:26PM +0200, demerphq wrote:
Attached patch fixes it in the TRIE(FL?)? code afaict.
D:\dev\perl\liveperl -Ilib -wle $x=qq[\xe9\x{100}]; chop $x; print 1
if qq[\xe9]=~/(abc|$x)/i
1
D:\dev\perl\liveperl -Ilib -wle $x=qq[\xe9\x{100}]; chop $x; print 1
if $x=~/(abc|\xe9)/i
1
thanks, applied as change #25106
I also added some tests.
--
That he said that that that that is is is debatable, is debatable.
Re: blead: new entry in the interperter for storing special contexts like ithreads?
On Fri, Jul 08, 2005 at 03:16:51PM +0300, Stas Bekman wrote: will it work w/o needing PERL_SET_CONTEXT(aTHX)? If we just make the first arg a ptr to an interpreter, then we can leave it to the caller how they get hold of my_perl. Most of the time we won't want perl_clone to do any cloning on it, since every new interpreter will want to set an explicit new value. so I'd think that perl_clone should always NULL it, no? in which case there is no need for a function (besides the identifier to find the entry in the linked list). In that case, your clone function can just set it to null. Other people's clone functions can do whatever they need. -- 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: [perl #35847] File::Find not performing as documented
On Fri, Jul 08, 2005 at 10:10:56AM -, Michael G Schwern via RT wrote:
I am unable to replicate this problem with either 5.8.1, 5.8.6 or
[EMAIL PROTECTED] I don't have a 5.8.3 handy to try.
I can:
#!/usr/bin/perl
mkdir 'x', 0777;
open F, 'x/f1';
open F, 'x/f2';
open F, 'x/f3';
use File::Find;
$File::Find::dont_use_nlink = $ARGV[0];
find sub { printf %s %s\n, -f _ ? 'file' : 'notf', $File::Find::name },
'x';
system 'rm -r x';
which gives:
$ ./perl -Ilib /tmp/p1 0
notf x
notf x/f2
notf x/f3
notf x/f1
$ ./perl -Ilib /tmp/p1 1
notf x
file x/f2
file x/f3
file x/f1
Its a problem as far back as 5.003_22 at least.
Basically, when it does the 'nlink check' shortcut on a directory to
determine whether the dir only contains files and no subdirs, it doesn't
bother lstating the individual entries in the dir to determine whether
they're a file or a subdir.
So we either fix the docs, as suggested, or fix the code to stat *every*
entry before calling the wanted function. The latter would defeat the
purpose of the optimisation, so I vote for the former.
--
But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged. -- Lady Croom - Arcadia
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Fri, Jul 08, 2005 at 09:36:19AM +0100, Steve Hay wrote:
The crash is deliberately forced by win32_checkTLS(), but I don't
understand for what reason. PerlEnvGetenv() takes an IPerlEnv* and uses
the IPERL2HOST() macro (which is set to IPerlEnv2Host()) to locate the
CPerlHost* which that IPerlEnv* is a member of. It then calls
win32_checkTLS() to check that the host_perl in the CPerlHost* that has
been found is my_perl. Evidently, in this case host_perl != my_perl, so
it bombs out.
Does anyone know what this my_perl is? What is the purpose of the
host_perl != my_perl check, and why might it be failing?
my_perl is a pointer to the current perl interpreter; in a threaded build,
it's normally passed as an extra 1st arg to most functions (that's what all
the pTHX/aTHX stuff is for); functions that don't get it passed can
have 'dTHX;' at their start, which declares my_perl and determines it from
thread-local storage (this is slow).
win32_checkTLS() appears to be sanity checking that the passed host_perl is
the same as the my_perl determined by dTHX; since is this happening during the
middle of cloning, this isn't likely to be the case.
The real question is why is PerlIO_debug() getting called for the first time
during cloning? On my system, it's getting called much earlier, during
perl_parse(). A second possibility is that it's not being called for the
first time, but that in this code:
PerlIO_debug(const char *fmt, ...)
{
va_list ap;
dSYS;
va_start(ap, fmt);
if (!PL_perlio_debug_fd !PL_tainting PL_uid == PL_euid PL_gid
== PL_egid) {
const char *s = PerlEnv_getenv(PERLIO_DEBUG);
if (s *s)
PL_perlio_debug_fd = PerlLIO_open3(s, O_WRONLY | O_CREAT |
O_APPEND, 0666);
else
PL_perlio_debug_fd = -1;
for some reason PerlLIO_open3() is setting PL_perlio_debug_fd to 0, so
that each time PerlIO_debug is called, it will still do a
PerlEnv_getenv(PERLIO_DEBUG). Perhaps?
Can you detemine when PerlIO_debug() is being called, and if whether it's
calling PerlLIO_open3() and whether that's rturning 0?
--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
- Nicholas Clark, based on an original by Simon Cozens.
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
On Fri, Jul 08, 2005 at 09:24:42AM +0200, demerphq wrote:
it turns out perl is totally borked for
$utf8 =~ /latin1/i
and
$latin1 =~ /$utf8/i
unless all the chars happen to be 0x7f.
The case where the pattern is /(foo|bar)/ is handled by a totally
different codepath in blead, does it also fail there? I seem to recall
that I put in tests for this, but possibly im wrong. Im flying on
holiday in less than 24 hours and i doubt Ill be able to check until i
return at the end of the month.
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if $x=~/(abc|\xe9)/i'
1
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if \xe9=~/(abc|$x)/i'
Malformed UTF-8 character (unexpected non-continuation byte 0x00, immediately
after start byte 0xe9) in pattern match (m//) at -e line 1.
--
Never do today what you can put off till tomorrow.
Re: blead: new entry in the interperter for storing special contexts like ithreads?
On Fri, Jul 08, 2005 at 02:07:13PM +0300, Stas Bekman wrote: 1) it should be set/get-able w/o requiring aTHX (or global context) 2) it must be not touched by perl (e.g. make perl_clone not touch it) we can start working with ithreads.xs to replace its Perl_ithread_set/get functions and then apply that to mod_perl2 as well. The solution is to just add a new entry to my_perl. But my_perl is just aTHX, so you *would* require aTHX (or dTHX). The question is what happens if more than one project wants to use that entry? There is no collision at the moment since mod_perl2's interpeters aren't touched by ithreads and the other way around, but may be in the future there will be such a need? How about (by analogy to mg), the new field in my_perl is a pointer to a linked list of structs that have 3 fields: data, fn, next data is a void * where you can put your private data; fn is a pointer to a function that is is called by perl_clone to clone the structure; it is also used as an identifier to disambiguate different users of the list. It would be wrapped in a simple API to add/delete an entry, or retrieve the data, eg PERL_INTERPRETER_DATA_ADD(data,my_func); data = PERL_INTERPRETER_DATA_GET(my_func); PERL_INTERPRETER_DATA_DELETE(my_func); -- I do not resent critisism, even when, for the sake of emphasis, it parts for the time with reality. -- Winston Churchill, House of Commons, 22nd Jan 1941.
Re: recent blead changes have introduced tainting problems
On Thu, Jul 07, 2005 at 03:14:47PM +0300, Stas Bekman wrote: i'm trying to get mod_perl2 working with blead, something has changed with the tainting, I now get: eval_sv(123;, G_SCALAR|G_KEEPERR); die with: Insecure dependency in eval_sv() while running with -T does it still fail post change 25081 ? -- O Unicef Clearasil! Gibberish and Drivel! - Bored of the Rings
Re: recent blead changes have introduced tainting problems
On Thu, Jul 07, 2005 at 02:24:08PM +0100, Dave Mitchell wrote: On Thu, Jul 07, 2005 at 03:14:47PM +0300, Stas Bekman wrote: i'm trying to get mod_perl2 working with blead, something has changed with the tainting, I now get: eval_sv(123;, G_SCALAR|G_KEEPERR); die with: Insecure dependency in eval_sv() while running with -T does it still fail post change 25081 ? Ignore that, I can reproduce it now -- The Enterprise successfully ferries an alien VIP from one place to another without serious incident. -- Things That Never Happen in Star Trek #7
Re: recent blead changes have introduced tainting problems
On Thu, Jul 07, 2005 at 02:39:33PM +0100, Dave Mitchell wrote:
eval_sv(123;, G_SCALAR|G_KEEPERR);
die with:
Insecure dependency in eval_sv() while running with -T
does it still fail post change 25081 ?
Ignore that, I can reproduce it now
fixed by the change below.
--
My get-up-and-go just got up and went.
Change 25094 by [EMAIL PROTECTED] on 2005/07/07 14:47:51
more taint fallout from change 24943
Affected files ...
... //depot/perl/mg.c#358 edit
... //depot/perl/scope.c#156 edit
... //depot/perl/t/op/taint.t#68 edit
Differences ...
//depot/perl/mg.c#358 (text)
@@ -1913,7 +1913,7 @@
Perl_magic_gettaint(pTHX_ SV *sv, MAGIC *mg)
{
PERL_UNUSED_ARG(sv);
-TAINT_IF(mg-mg_len 1);
+TAINT_IF((PL_localizing != 1) (mg-mg_len 1));
return 0;
}
//depot/perl/scope.c#156 (text)
@@ -170,7 +170,9 @@
Perl_save_scalar(pTHX_ GV *gv)
{
SV **sptr = GvSV(gv);
+PL_localizing = 1;
SvGETMAGIC(*sptr);
+PL_localizing = 0;
SSCHECK(3);
SSPUSHPTR(SvREFCNT_inc(gv));
SSPUSHPTR(SvREFCNT_inc(*sptr));
//depot/perl/t/op/taint.t#68 (xtext)
@@ -17,7 +17,7 @@
use File::Spec::Functions;
BEGIN { require './test.pl'; }
-plan tests = 243;
+plan tests = 244;
$| = 1;
@@ -1128,3 +1128,10 @@
test tainted $x99;
}
+# an mg_get of a tainted value during localization shouldn't taint the
+# statement
+
+{
+eval { local $0, eval '1' };
+test $@ eq '';
+}
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Thu, Jul 07, 2005 at 01:56:39PM +0100, Steve Hay wrote: Hmm. I just retried this with current blead and I find that it (apparently) works OK with a debug build, but crashes with a release build. I can't get it to crash on either type of build (Linux). Fortunately, release builds on Win32 have debugging symbols anyway (since they are stored in separate files), so I am able to get a stack trace: win32_checkTLS(interpreter * 0x73204441) line 57 PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string') line 454 + 19 bytes PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494, clone_params * 0x0140fc80) line 643 perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem * 0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv * 0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir * 0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383 perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67 bytes perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes Perl_ithread_create(interpreter * 0x, sv * 0x, char * 0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes XS_threads_new(interpreter * 0x0002, cv * 0x018a83f4) line 687 + 32 bytes Perl_pp_entersub(interpreter * 0x01234494) line 2789 Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes perl_run(interpreter * 0x00234494) line 2160 + 10 bytes RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes PERL! mainCRTStartup + 227 bytes KERNEL32! 77e8141a() threads-new() tries to clone an intepreter; this calls PerlIO_clone(), which calls PerlIO_debug(), which tries to get the value (if any) of the env var PERLIO_DEBUG. At this point it jumps into windows-specific code, where it then crashes. Does it still fail after change 25094? I'm pretty much clutching at straws here, but that does hapen to fix an unrelated bug associated with doing 'local $0' -- Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. -- Dennis - Monty Python and the Holy Grail.
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
On Tue, Jun 07, 2005 at 04:28:08PM -, Nicholas Clark wrote:
./perl -Ilib -we '$term = \xe9; $target = \xe9\x{100}; chop $target;
$target =~ /$term/i'
Malformed UTF-8 character (unexpected non-continuation byte 0x00, immediately
after start byte 0xe9) in pattern match (m//) at -e line 1.
it turns out perl is totally borked for
$utf8 =~ /latin1/i
and
$latin1 =~ /$utf8/i
unless all the chars happen to be 0x7f.
The patch below fixes the first case: the fault was in ibcmp_utf8(),
which was calling to_utf8_fold() without first converting the char to
utf8.
The second case fails in S_find_byclass() in regexec.c:
while (s = e) {
if ( (*(U8*)s == c1 || *(U8*)s == c2)
(ln == 1 || !(OP(c) == EXACTF
? ibcmp(s, m, ln)
: ibcmp_locale(s, m, ln)))
(norun || regtry(prog, s)) )
goto got_it;
s++;
}
where it calls ibcmp() but s is a pointer to a latin1 while m is pointer
to a utf8 char. I don't really understand this code well enough to feel
confident fixing it. In fact I'm not even totally confident in my fix for
the first case, hence I'm Ccing everyone's Favourite Finn.
Dave.
--
But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged. -- Lady Croom - Arcadia
Change 25095 by [EMAIL PROTECTED] on 2005/07/08 01:43:24
[perl #36207] UTF8/Latin 1/i regexp Malformed character warning
$utf8 =~ /latin/i didn't match.
Also added TODO for $latin =~ /utf8/i which also fails
Affected files ...
... //depot/perl/t/op/pat.t#222 edit
... //depot/perl/utf8.c#239 edit
Differences ...
//depot/perl/t/op/pat.t#222 (xtext)
@@ -6,7 +6,7 @@
$| = 1;
-print 1..1178\n;
+print 1..1180\n;
BEGIN {
chdir 't' if -d 't';
@@ -3364,4 +3364,14 @@
my $psycho=join |,@normal,map chr $_,255..2;
ok(('these'=~/($psycho)/) $1 eq 'these','Pyscho');
}
-# last test 1178
+
+# [perl #36207] mixed utf8 / latin-1 and case folding
+
+{
+my $u = \xe9\x{100};
+chop $u;
+ok($u =~ /\xe9/i, utf8/latin);
+ok(\xe9 =~ /$u/i, # TODO latin/utf8);
+}
+
+# last test 1180
//depot/perl/utf8.c#239 (text)
@@ -2037,7 +2037,7 @@
if (u1)
to_utf8_fold(p1, foldbuf1, foldlen1);
else {
- natbuf[0] = *p1;
+ uvuni_to_utf8(natbuf, (UV) NATIVE_TO_UNI(((UV)*p1)));
to_utf8_fold(natbuf, foldbuf1, foldlen1);
}
q1 = foldbuf1;
@@ -2047,7 +2047,7 @@
if (u2)
to_utf8_fold(p2, foldbuf2, foldlen2);
else {
- natbuf[0] = *p2;
+ uvuni_to_utf8(natbuf, (UV) NATIVE_TO_UNI(((UV)*p2)));
to_utf8_fold(natbuf, foldbuf2, foldlen2);
}
q2 = foldbuf2;
Re: [perl #19088] Thread::Queue
On Wed, Jul 06, 2005 at 08:32:52AM -0700, Michael G Schwern wrote:
The original is like:
sub dequeue {
my $q = shift;
lock(@$q);
cond_wait @$q until @$q;
cond_signal @$q if @$q 1;
return shift @$q;
}
Should it be safer if it goes like this?
sub dequeue {
my $q = shift;
lock(@$q);
cond_wait @$q until @$q;
my $p = shift @$q;
cond_signal @$q if @$q = 1;
return $p;
}
The original code is safe as-is. The whole body of dequeue occurs while
it has the lock on @$q (apart from temporarily relinquishing it during
cond_wait). The cond_signal bit is only for the specific case that more
than one item was pushed onto the queue, and that there is more than one
consumer thread waiting to remove it: the first thread to get its snout
in the trough signals to its compatriots (if any) that there is more
data available: one of those compatriots will be awoken and will try to
grab the lock; in the meantime the first consumer still has the lock,
pulls one item from the queue and returns it, freeing up the lock. At
which point the second compatriot will get the lock and ppop one too.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
Re: Smoke [5.9.3] 25079 FAIL(F) AIX 4.3.3.0/ML11 (PPC/1 cpu)
On Wed, Jul 06, 2005 at 06:21:42PM +0200, H.Merijn Brand wrote:
On Tue, 5 Jul 2005 21:07:15 +0100, Dave Mitchell [EMAIL PROTECTED] wrote:
pp_hot.c, line 2682.9: 1506-235 (W) Incorrect escape sequence \C. \
I'm mystified by this. My recent changes should have removed the macro
expansions on those lines to 512 bytes, which was Nick's theory as to why
they were failing.
Could you do the following on a failing config?
$ make pp_hot.i
$ grep set_cur pp_hot.i | od -c
000( m y _ p e r l - I c o m p
020p a d ) = ( P A D * ) ( (
040( p a d l i s t ) - s v _ u .
060s v u _ a r r a y ) [ ( ( X P V
100C V * ) ( c v ) - s v _ a n y
120) - x c v _ d e p t h ] ) ;
140( m y _ p e r l - T c u r p a
160d ) = ( ( ( m y _ p e r l -
200 I c o m p p a d ) ) - s v _
220u . s v u _ a r r a y ) ; ( v
240o i d ) ( { i f ( ( ( ( m
260y _ p e r l - I d e b u g )
300 0 x 0 0 0 0 4 0 0 0 )
320( ( m y _ p e r l - I d e b
340u g ) 0 x 0 0 1 0 0 0 0 0
360) ) ) ( v o i d ) ( { P e r
400l I O _ p r i n t f ( P e r l _
420P e r l I O _ s t d e r r ( m y
440_ p e r l ) , P a d 0 x %
460 l x [ 0 x % l x
500] s e t _ c u r d e p
520t h = % d \ n , ( U V ) ( (
540m y _ p e r l - I c o m p p a
560d ) ) , ( U V ) ( ( m y _ p e
600r l - T c u r p a d ) ) , (
620i n t ) ( ( ( X P V C V * ) ( c
640v ) - s v _ a n y ) - x c v
660_ d e p t h ) ) ; } ) ; }
700) ; ; \n
704
Hmmm, exactly the same as on my system: no strange control chars, and the
line length is 452, safely below 512. I'm fresh out of ideas.
--
The Enterprise is involved in a bizarre time-warp experience which is in
some way unconnected with the Late 20th Century.
-- Things That Never Happen in Star Trek #14
Re: [perl #36470] IO::Socket::INET triggers 'Use of uninitialized value in die' when no die string given
On Wed, Jul 06, 2005 at 03:38:22PM -, avised @ kbcfp. com wrote:
The following test program
use warnings;
use IO::Socket;
IO::Socket::INET-new(PeerAddr = 'localhost',
PeerPort = '23',
);
die;
produces the error output
Use of uninitialized value in die at ./test line 7.
Died at ./test line 7.
Thanks for the report; the test case be reduced to
undef $@; die;
Fixed in bleedperl by the change below.
Dave.
--
The greatest achievement of the Austrians has been convincing the world
that Hitler was German, and Mozart Austrian.
Change 25087 by [EMAIL PROTECTED] on 2005/07/06 20:09:29
[perl #36470] 'undef $@; die' gives uninint value warning
Affected files ...
... //depot/perl/pp_sys.c#429 edit
... //depot/perl/t/op/die.t#5 edit
Differences ...
//depot/perl/pp_sys.c#429 (text)
@@ -517,7 +517,10 @@
if (SvPOK(error) SvCUR(error))
sv_catpv(error, \t...propagated);
tmpsv = error;
- tmps = SvPV_const(tmpsv, len);
+ if (SvOK(tmpsv))
+ tmps = SvPV_const(tmpsv, len);
+ else
+ tmps = Nullch;
}
}
if (!tmps || !len)
//depot/perl/t/op/die.t#5 (xtext)
@@ -1,6 +1,6 @@
#!./perl
-print 1..14\n;
+print 1..15\n;
$SIG{__DIE__} = sub { print ref($_[0]) ? (ok ,$_[0]-[0]++,\n) : @_ } ;
@@ -61,3 +61,14 @@
print not unless $@ =~ /Global symbol \$\x{3b1}/;
print ok 14\n;
}
+
+# [perl #36470] got uninit warning if $@ was undef
+
+{
+my $ok = 1;
+local $SIG{__DIE__};
+local $SIG{__WARN__} = sub { $ok = 0 };
+eval { undef $@; die };
+print not unless $ok;
+print ok 15\n;
+}
Re: [perl #34171] bytes pragma error in substitution operator
On Thu, Feb 17, 2005 at 09:24:53PM -, dgeorge @ cas. org wrote:
use strict;
use bytes;
use XML::DOM;
# XML document
my $xml = doc\xe2\x80\x98WOW\xe2\x80\x99/doc;
# XML parser
my $parser = new XML::DOM::Parser;
# Document Object Model
my $dom = $parser-parse($xml, ProtocolEncoding = 'UTF-8');
# Element content
my $content = $dom-getDocumentElement()-getFirstChild()-getNodeValue();
# Print length of $content(should be 9 and is 9)
print 'Length of $content = ', unpack(H*, $content), ' is ',
length($content), \n;
# Print length of $1(should be 3 1 1 1 3 and is 1 1 1 1 3)
$content =~
s/([\x00-\x7f]|[\xc0-\xdf].|[\xe0-\xef]..|[\xf0-\xf7]...|[\xf8-\xfb]|[\xfc-\xfd].)/print
'Length of $1 = ', unpack(H*, $1), ' is ', length($1), \n/eg;
Fixed in bleedperl by the change below
--
In my day, we used to edit the inodes by hand. With magnets.
Change 25088 by [EMAIL PROTECTED] on 2005/07/07 00:11:00
[perl #34171] bytes pragma error in substitution operator
Affected files ...
... //depot/perl/pp_ctl.c#464 edit
... //depot/perl/t/op/subst.t#43 edit
Differences ...
//depot/perl/pp_ctl.c#464 (text)
@@ -204,7 +204,7 @@
}
rxres_restore(cx-sb_rxres, rx);
-RX_MATCH_UTF8_set(rx, SvUTF8(cx-sb_targ));
+RX_MATCH_UTF8_set(rx, DO_UTF8(cx-sb_targ));
if (cx-sb_iters++) {
const I32 saviters = cx-sb_iters;
//depot/perl/t/op/subst.t#43 (xtext)
@@ -7,7 +7,7 @@
}
require './test.pl';
-plan( tests = 130 );
+plan( tests = 131 );
$x = 'foo';
$_ = x;
@@ -539,3 +539,17 @@
$name =~ s/hr//e;
}
is($name, cis, q[#22351 bug with 'e' substitution modifier]);
+
+
+# [perl #34171] $1 didn't honour 'use bytes' in s//e
+{
+my $s=\x{100};
+my $x;
+{
+ use bytes;
+ $s=~ s/(..)/$x=$1/e
+}
+is(length($x), 2, '[perl #34171]');
+}
+
+
Re: [perl #34180] segfault in perl_clone under ithreads and custom PerlIO layer
On Sat, Feb 19, 2005 at 02:20:28AM -, Stas Bekman wrote:
We have yet another chicken-n-egg problem with perl_clone. If you do a
simple:
use threads;
my $thread = threads-create(sub {}, undef)
and STDOUT is opened to some PerlIO layer, an attempt to clone it will be
performed. The problem is that this cloning happens too early:
do you have a complete script that reproduces this?
something simple like
binmode STDOUT, ':utf8';
didn't segfault
--
Counsellor Troi states something other than the blindingly obvious.
-- Things That Never Happen in Star Trek #16
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Thu, Feb 24, 2005 at 01:32:25PM +, Steve Hay wrote:
Stas Bekman wrote:
The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
#!/usr/bin/perl -T
use Devel::Peek;
use threads;
local $0 = test; # == XXX: leaks scalar
my $thr = threads-new(sub { Dump $0 });
$thr-join;# == XXX: triggers the leak
[...]
Scalars leaked: 1
leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter: 0x8102770
As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
object is a taint magic (and it happens under -T).
Is this anything to do with the following comment found in
scope.c::S_save_scalar_at()
/* XXX SvMAGIC() is *shared* between osv and sv. This can
* lead to coredumps when both SVs are destroyed without one
* of their SvMAGIC() slots being NULLed. */
Looks like the leak has been fixed by my change #24942, which fixed
local() and magic (and specifically removed the code related to that XXX
comment above)
--
Do not dabble in paradox, Edward, it puts you in danger of fortuitous
wit. -- Lady Croom - Arcadia
Re: [perl #34390] Data::Dumper misprints newline character
On Wed, Mar 09, 2005 at 06:08:38PM -, echang @ pixar. com wrote: When the following is read in from a file and then printed out using Data::Dumper, the y-umlaut character causes the newline character right after to be printed without a leading \. Input file: parser: parse error near ÿ So when this is dumped to a file in perl code it should be printed out as: parser: parse error near \ÿ\ but instead it's printed as: parser: parse error near \\377 Since the no longer has the leading slash, the quote contexts are messed up in the perl output file Data::Dumper creates. Also the change from y-umlaut to \377 is a problem, but not as big as the missing \ on the . Do you have a short, self-contained script that reproduces the problem? -- 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: Change 24943: remove taint hack now that local $tainted no longer copies taint magic
On Tue, Jul 05, 2005 at 02:42:59AM +0100, Dave Mitchell wrote:
On Mon, Jul 04, 2005 at 11:16:21PM +0100, Nicholas Clark wrote:
This breaks t/spamd_hup.t in Mail-Spamassassin.
I've reduced it to the following. Looks like some sort of problem
localizing hash slices. Will look into it further tomorrow sometime.
hash slice was a red-herring - it was a general problem unlocalizing
tainted values. Change 24943 basiucally threw out the baby with the
bathwater.
Fixed by the change below.
--
I've often wanted to drown my troubles, but I can't get my wife to go
swimming.
Change 25081 by [EMAIL PROTECTED] on 2005/07/05 13:01:23
change 24943 broke restoration of localized taint values
Affected files ...
... //depot/perl/mg.c#357 edit
... //depot/perl/t/op/taint.t#67 edit
Differences ...
//depot/perl/mg.c#357 (text)
@@ -1921,10 +1921,13 @@
Perl_magic_settaint(pTHX_ SV *sv, MAGIC *mg)
{
PERL_UNUSED_ARG(sv);
-if (PL_tainted)
- mg-mg_len |= 1;
-else
- mg-mg_len = ~1;
+/* update taint status unless we're restoring at scope exit */
+if (PL_localizing != 2) {
+ if (PL_tainted)
+ mg-mg_len |= 1;
+ else
+ mg-mg_len = ~1;
+}
return 0;
}
//depot/perl/t/op/taint.t#67 (xtext)
@@ -17,7 +17,7 @@
use File::Spec::Functions;
BEGIN { require './test.pl'; }
-plan tests = 238;
+plan tests = 243;
$| = 1;
@@ -1106,3 +1106,25 @@
test not any_tainted @bar;
}
}
+
+# at scope exit, a restored localised value should have its old
+# taint status, not the taint status of the current statement
+
+{
+our $x99 = $^X;
+test tainted $x99;
+
+$x99 = '';
+test not tainted $x99;
+
+my $c = do { local $x99; $^X };
+test not tainted $x99;
+}
+{
+our $x99 = $^X;
+test tainted $x99;
+
+my $c = do { local $x99; '' };
+test tainted $x99;
+}
+
Re: Date::Parse (Time::Local?) choking on years between 1956-1938 and wrong below, on FC4/5.8.6
On Tue, Jul 05, 2005 at 10:30:02AM -0700, Scott Godin wrote: $ date -d 'July 4, 1901' +%s | perl -lne 'print scalar localtime $_' Fri Dec 13 15:45:52 1901 $ date -d 'July 4, 1902' +%s | perl -lne 'print scalar localtime $_' Fri Jul 4 00:00:00 1902 but clearly, neither do perl's (for the date ranges I actually need). something else is indeed wonky within Date::Parse. Please investigate. Two comments. First, Date::Parse is not part of the perl core, therefore you will need to raise any issues with the module's author rather than with us. Second, there are absolutely no guarantees what will happen on UNIX systems for dates 1970. It so happens that on your system, the system libraries appear to be treating the time value as a signed number, so dates happen to range from Dec 1901 to Jan 2038; on other systems it can be viewed as an unsigned number, so dates can range from 1970 to 2106. If you want to write portable code that handles dates outside the 1970-2037 range, then don't use libraries that return a UNIX-style seconds-since-1970 value. Note that perl's localtime and gmtime functions just call the underlying C library localtime and gmtime functions. -- Lady Nancy Astor: If you were my husband, I would flavour your coffee with poison. Churchill: Madam - if I were your husband, I would drink it.
Re: [PATCH] Re: [PATCH] Re: a blead warning from tru64
On Mon, Jul 04, 2005 at 09:32:58AM +0300, Jarkko Hietaniemi wrote: .. you forgot the while wearing a garland of garlic bit. Change the aTHX_ in my patch to pTHX_ and things should look better. The garlic did the trick. Thanks, applied as change #25057 -- The GPL violates the U.S. Constitution, together with copyright, antitrust and export control laws -- SCO smoking crack again.
Re: Comparing a datetime and a scalar?
On Mon, Jul 04, 2005 at 09:01:46AM -0400, Albert Whale wrote: I am trying to test the value of a MySQL datetime string to the current time. I have the following code fragment but the comparison fails: This list is for the development fo the perl interpreter itself. For general Perl programming questions, I'd suggest somewhere like http://www.perlmonks.org/ -- SCO - a train crash in slow motion
Re: [perl #34035] Segfault involving goto and loops
On Mon, Jul 04, 2005 at 02:44:28PM -, Steve Peters via RT wrote: It looks like this has been fixed in bleadperl, but I'm not sure when. by change #24384, which was a fix for a similar bug report [perl #35214] -- Fire extinguisher (n) a device for holding open fire doors.
Re: Change 24943: remove taint hack now that local $tainted no longer copies taint magic
On Mon, Jul 04, 2005 at 11:16:21PM +0100, Nicholas Clark wrote: On Wed, Jun 22, 2005 at 04:44:29PM -0700, Dave Mitchell wrote: Change 24943 by [EMAIL PROTECTED] on 2005/06/22 23:08:55 remove taint hack now that local $tainted no longer copies taint magic Affected files ... ... //depot/perl/mg.c#352 edit ... //depot/perl/sv.c#926 edit This breaks t/spamd_hup.t in Mail-Spamassassin. Bugger. Are you abolutely certain it's 24943 rather than 24942? The latter makes a big change to local/magic, while 24943 should just be removing a bit of code made obsolete by 24942. -- Little fly, thy summer's play my thoughtless hand has terminated with extreme prejudice. (with apologies to William Blake)
Re: Change 24943: remove taint hack now that local $tainted no longer copies taint magic
On Mon, Jul 04, 2005 at 11:16:21PM +0100, Nicholas Clark wrote:
This breaks t/spamd_hup.t in Mail-Spamassassin.
I've reduced it to the following. Looks like some sort of problem
localizing hash slices. Will look into it further tomorrow sometime.
use Scalar::Util qw(tainted);
warn sprintf start tainted=%d\n, tainted($ENV{PATH});
$ENV{PATH} = '/bin';
warn sprintf set tainted=%d\n, tainted($ENV{PATH});
my $c = do {
local @ENV{qw(PATH IFS)};
my $cwd = ``;
$cwd;
};
warn sprintf CWD tainted=%d\n, tainted($ENV{PATH});
$ ./perl -Ilib -T -w /tmp/p
start tainted=1
set tainted=0
CWD tainted=1
$
--
In England there is a special word which means the last sunshine
of the summer. That word is spring.
Re: Smoke [5.9.3] 25055 FAIL(F) bsd/os 4.1 (i386/1 cpu)
On Sun, Jul 03, 2005 at 01:57:00PM +0200, [EMAIL PROTECTED] wrote:
Automated smoke report for 5.9.3 patch 25055
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 56 minutes (average 1 hour 58 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
25055 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
Has anyone looked into this at all?
It's this test:
$x = 4294967295.7;
$y = int ($x);
if ($y eq 4294967295) {
print ok 11\n
} else {
print not ok 11 # int($x) is $y, not 4294967295\n
}
would be interesting to see what value $y actually has.
Dave.
--
You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad.
-- Monty Python - Finland
Re: [PATCH] Re: [PATCH] Re: a blead warning from tru64
On Sun, Jul 03, 2005 at 11:22:19AM +0300, Jarkko Hietaniemi wrote: Jarkko Hietaniemi wrote: Jarkko Hietaniemi wrote: cc: Warning: perl.h, line 4175: In the initializer for PL_vtbl_arylen.svt_get, the referenced type of the pointer value Perl_magic_getarylen is function (pointer to struct sv, pointer to const struct magic) returning int, which is not compatible with function (pointer to struct sv, pointer to struct magic) returning int. (ptrmismatch) MGVTBL_SET( ^ A patch for this is attached. Uh-oh. A working patch is attached in here. First time I've seen a zero-length file described as a working patch :-( -- Please note that ash-trays are provided for the use of smokers, whereas the floor is provided for the use of all patrons. -- Bill Royston
Re: [PATCH] Re: [PATCH] Re: a blead warning from tru64
On Mon, Jul 04, 2005 at 12:19:28AM +0300, Jarkko Hietaniemi wrote:
Just rotate the bits 90 degrees clockwise, shake well, and look against
a strong light. Oh, right, there are no bits to rotate. Try these bits.
Under a full moon while standing with one trouser leg rolled up??
The patch dies horribly on a threaded build :-(
`sh cflags optimize='-g' globals.o` globals.c
CCCMD = cc -DPERL_CORE -c -D_REENTRANT -D_GNU_SOURCE
-DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -g -Wall
In file included from globals.c:35:
perl.h:4177: error: syntax error before my_perl
--- perl.h.dist 2005-07-03 11:09:01.0 +0300
+++ perl.h2005-07-03 11:20:46.0 +0300
@@ -4050,8 +4050,10 @@
#ifdef DOINIT
# define MGVTBL_SET(var,a,b,c,d,e,f,g) EXTCONST MGVTBL var = {a,b,c,d,e,f,g}
+# define MGVTBL_SET_CONST_MAGIC_GET(var,a,b,c,d,e,f,g) EXTCONST MGVTBL var
= {(int (*)(aTHX_ SV *, MAGIC *))a,b,c,d,e,f,g} /* Like MGVTBL_SET but with
the get magic having a const MG* */
#else
# define MGVTBL_SET(var,a,b,c,d,e,f,g) EXTCONST MGVTBL var
+# define MGVTBL_SET_CONST_MAGIC_GET(var,a,b,c,d,e,f,g) EXTCONST MGVTBL var
#endif
MGVTBL_SET(
@@ -4172,7 +4174,7 @@
NULL
);
-MGVTBL_SET(
+MGVTBL_SET_CONST_MAGIC_GET(
PL_vtbl_arylen,
MEMBER_TO_FPTR(Perl_magic_getarylen),
MEMBER_TO_FPTR(Perl_magic_setarylen),
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
perl is getting slower/faster/slower/faster
For fun, I cobbled together a crude benchmark script that just reads
/etc/services and constructs several pointless hashes from it, which it
then searches in pointless and inefficient ways.
I then ran it agins all the -O bleedperls I have lying around from the
last couple of years. I ran it 4 times against each to get an average.
Here are the results. The basic conclusion seems to be that from time to
time we break perl perfomance-wise, then claw it back again.
Suggestions for better benchmark scripts welome.
Times are in seconds, so smaller is better.
11239 27.55 +/- 0.39
11724 26.55 +/- 0.29
15309 25.88 +/- 0.18
16732 67.65 +/- 0.56
17319 57.21 +/- 0.53
17396 57.44 +/- 0.66
17655 64.45 +/- 0.23
17721 66.88 +/- 0.09
17735 61.54 +/- 0.22
17914 65.28 +/- 0.26
17974 57.49 +/- 0.22
18020 59.52 +/- 0.61
18113 57.05 +/- 0.41
18125 57.64 +/- 0.32
18589 27.53 +/- 0.07
18597 27.28 +/- 0.12
18702 27.73 +/- 0.12
18779 28.21 +/- 0.90
18793 27.56 +/- 0.08
19021 28.34 +/- 0.22
19042 27.48 +/- 0.06
19143 27.85 +/- 0.56
19162 27.52 +/- 0.29
19306 26.71 +/- 0.17
19523 27.58 +/- 1.01
19528 27.61 +/- 0.84
19595 26.87 +/- 0.16
19610 25.63 +/- 0.15
19622 25.55 +/- 0.07
19629 25.54 +/- 0.35
19642 25.12 +/- 0.10
19664 25.12 +/- 0.23
19708 25.93 +/- 0.16
19834 25.76 +/- 0.18
19853 25.75 +/- 0.23
19867 25.56 +/- 0.44
19917 25.75 +/- 0.32
20012 25.53 +/- 0.19
20156 25.12 +/- 0.33
20159 25.02 +/- 0.18
20182 25.33 +/- 0.41
20267 25.64 +/- 0.78
20514 26.71 +/- 3.30
20579 25.32 +/- 0.31
20619 25.86 +/- 0.38
20710 25.77 +/- 0.33
20809 25.99 +/- 0.46
20915 25.79 +/- 0.46
21061 26.50 +/- 1.36
21137 24.76 +/- 0.12
21214 25.73 +/- 0.73
21323 25.38 +/- 0.42
21436 25.69 +/- 0.24
21471 25.59 +/- 0.33
21583 25.84 +/- 0.50
21802 33.34 +/- 0.16
21874 32.39 +/- 0.40
21978 27.91 +/- 1.28
22047 28.75 +/- 0.43
22160 28.68 +/- 0.35
22168 29.70 +/- 0.53
22243 30.54 +/- 1.34
22298 28.56 +/- 0.49
22303 28.82 +/- 0.18
22352 28.95 +/- 0.11
22375 31.70 +/- 0.31
22414 33.00 +/- 0.75
22444 35.48 +/- 0.55
22481 34.58 +/- 0.38
22524 30.41 +/- 0.73
22582 28.07 +/- 0.15
22621 28.32 +/- 0.23
22682 28.67 +/- 0.47
22741 28.32 +/- 0.30
22758 28.28 +/- 0.21
22802 28.31 +/- 0.32
22818 28.43 +/- 0.59
22838 28.25 +/- 0.30
22853 28.18 +/- 0.23
22901 27.99 +/- 0.33
22912 28.16 +/- 0.16
22949 27.88 +/- 0.37
22960 28.17 +/- 0.55
23027 28.21 +/- 0.10
23073 28.70 +/- 1.41
23130 28.12 +/- 0.29
23158 28.41 +/- 0.07
23168 28.44 +/- 0.40
23178 28.40 +/- 0.15
23213 29.41 +/- 0.61
23280 29.24 +/- 0.05
23334 28.61 +/- 0.52
23341 29.09 +/- 0.90
23354 29.09 +/- 0.90
23492 28.23 +/- 0.13
23618 27.93 +/- 0.54
23712 24.05 +/- 0.34
23763 23.98 +/- 0.16
23805 23.58 +/- 0.40
23842 23.48 +/- 0.10
23973 23.15 +/- 0.10
23990 23.09 +/- 0.12
24002 23.14 +/- 0.18
24074 23.30 +/- 0.09
24149 23.39 +/- 0.11
24231 24.59 +/- 0.16
24249 24.34 +/- 0.16
24280 24.84 +/- 0.06
24381 24.94 +/- 0.09
24405 25.91 +/- 0.11
24501 25.55 +/- 0.50
24578 25.49 +/- 0.23
24651 24.64 +/- 0.05
24796 25.41 +/- 0.09
25006 25.38 +/- 0.11
25055 24.85 +/- 0.27
--
The Enterprise is captured by a vastly superior alien intelligence which
does not put them on trial.
-- Things That Never Happen in Star Trek #10
#!/usr/bin/perl
use strict;
use warnings;
my %services;
{
while () {
s/#.*$//;
next unless /\S/;
my ($srv, $portproto, @aliases) = split;
my ($port, $proto) = split /\//, $portproto;
for my $svcs ($srv, @aliases) {
for (0..9) {
$services{lc $svcs}{$proto$_} = $port;
}
}
}
}
my %charcounts;
{
for my $char ('a'..'z') {
my $qr = qr/$char/;
for (keys %services) {
$charcounts{$char}++ if $_ =~ $qr;
}
}
}
my %combo;
my %whoohoo;
{
for my $service (sort keys %services) {
for my $proto (sort keys %{$services{$service}}) {
for my $port (0..65535) {
if ($port == $services{$service}{$proto}) {
my $id = $service-$proto-$port;
$combo{$id}++;
$whoohoo{$id}++ if $id =~ /(d|ser)-tcp?-\d+/;
last;
}
}
}
}
}
printf %2.5f\n, times;
demacroize ckWARN*
The various macros ckWARN* are big and clunky, and are used about 600
times in the core. Since they are usually evaluated only in 'this
shouldn't be happening' codepaths, there doesn't seem to be any benefit
in avoiding a function call.
The patch below adds functions to do the bulk of the macros, and reduces
the size of the perl executable by 2% (!), and according to make test, is
fractionally faster (but that is most likely noise).
Dave.
--
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
(with apologies to William Blake)
Change 25050 by [EMAIL PROTECTED] on 2005/07/02 15:05:04
replace ckWARN macros with functions
Affected files ...
... //depot/perl/embed.fnc#218 edit
... //depot/perl/embed.h#496 edit
... //depot/perl/pod/perlintern.pod#42 edit
... //depot/perl/proto.h#569 edit
... //depot/perl/util.c#477 edit
... //depot/perl/warnings.h#26 edit
... //depot/perl/warnings.pl#47 edit
Differences ...
//depot/perl/embed.fnc#218 (text)
@@ -1524,6 +1524,8 @@
#ifdef PERL_DONT_CREATE_GVSV
Ap |GV*|gv_SVadd |NN GV* gv
#endif
+po |bool |ckwarn |U32 w
+po |bool |ckwarn_d |U32 w
p |void |offer_nice_chunk |NN void *chunk|U32 chunk_size
//depot/perl/embed.h#496 (text+w)
@@ -3619,6 +3619,8 @@
#define gv_SVadd(a)Perl_gv_SVadd(aTHX_ a)
#endif
#ifdef PERL_CORE
+#endif
+#ifdef PERL_CORE
#define offer_nice_chunk(a,b) Perl_offer_nice_chunk(aTHX_ a,b)
#endif
#define ck_anoncode(a) Perl_ck_anoncode(aTHX_ a)
//depot/perl/pod/perlintern.pod#42 (text+w)
@@ -224,7 +224,12 @@
=item PAD_SET_CUR
Set the current pad to be pad Cn in the padlist, saving
-the previous current pad.
+the previous current pad. NB currently this macro expands to a string too
+long for some compilers, so it's best to replace it with
+
+SAVECOMPPAD();
+PAD_SET_CUR_NOSAVE(padlist,n);
+
voidPAD_SET_CUR (PADLIST padlist, I32 n)
//depot/perl/proto.h#569 (text+w)
@@ -2995,6 +2995,8 @@
__attribute__nonnull__(pTHX_1);
#endif
+PERL_CALLCONV bool Perl_ckwarn(pTHX_ U32 w);
+PERL_CALLCONV bool Perl_ckwarn_d(pTHX_ U32 w);
PERL_CALLCONV void Perl_offer_nice_chunk(pTHX_ void *chunk, U32 chunk_size)
__attribute__nonnull__(pTHX_1);
//depot/perl/util.c#477 (text)
@@ -1376,6 +1376,58 @@
}
}
+/* implements the ckWARN? macros */
+
+bool
+Perl_ckwarn(pTHX_ U32 w)
+{
+return
+ (
+ isLEXWARN_on
+PL_curcop-cop_warnings != pWARN_NONE
+(
+ PL_curcop-cop_warnings == pWARN_ALL
+ || isWARN_on(PL_curcop-cop_warnings, unpackWARN1(w))
+ || (unpackWARN2(w)
+isWARN_on(PL_curcop-cop_warnings, unpackWARN2(w)))
+ || (unpackWARN3(w)
+isWARN_on(PL_curcop-cop_warnings, unpackWARN3(w)))
+ || (unpackWARN4(w)
+isWARN_on(PL_curcop-cop_warnings, unpackWARN4(w)))
+ )
+ )
+ ||
+ (
+ isLEXWARN_off PL_dowarn G_WARN_ON
+ )
+ ;
+}
+
+/* implements the ckWARN?_d macro */
+
+bool
+Perl_ckwarn_d(pTHX_ U32 w)
+{
+return
+ isLEXWARN_off
+ || PL_curcop-cop_warnings == pWARN_ALL
+ || (
+ PL_curcop-cop_warnings != pWARN_NONE
+ (
+ isWARN_on(PL_curcop-cop_warnings, unpackWARN1(w))
+ || (unpackWARN2(w)
+ isWARN_on(PL_curcop-cop_warnings, unpackWARN2(w)))
+ || (unpackWARN3(w)
+ isWARN_on(PL_curcop-cop_warnings, unpackWARN3(w)))
+ || (unpackWARN4(w)
+ isWARN_on(PL_curcop-cop_warnings, unpackWARN4(w)))
+ )
+ )
+ ;
+}
+
+
+
/* since we've already done strlen() for both nam and val
* we can use that info to make things faster than
* sprintf(s, %s=%s, nam, val)
//depot/perl/warnings.h#26 (text+w)
@@ -88,61 +88,15 @@
#define isWARN_on(c,x) (IsSet(SvPVX_const(c), 2*(x)))
#define isWARNf_on(c,x)(IsSet(SvPVX_const(c), 2*(x)+1))
-#define ckWARN(x) \
- ( (isLEXWARN_on PL_curcop-cop_warnings != pWARN_NONE \
- (PL_curcop-cop_warnings == pWARN_ALL || \
- isWARN_on(PL_curcop-cop_warnings, x) ) )\
- || (isLEXWARN_off PL_dowarn G_WARN_ON) )
+#define ckWARN(w) Perl_ckwarn(aTHX_ packWARN(w))
+#define ckWARN2(w1,w2) Perl_ckwarn(aTHX_ packWARN2(w1,w2))
+#define ckWARN3(w1,w2,w3) Perl_ckwarn(aTHX_ packWARN3(w1,w2,w3))
+#define ckWARN4(w1,w2,w3,w4) Perl_ckwarn(aTHX_ packWARN4(w1,w2,w3,w4))
-#define ckWARN2(x,y) \
- ( (isLEXWARN_on PL_curcop-cop_warnings !=
Re: demacroize ckWARN*
On Sat, Jul 02, 2005 at 04:52:43PM +0100, [EMAIL PROTECTED] wrote: If I remember right, a lot of code tests whether the warning is enabled before testing whether the warning case applies, on the assumption that the first check is quick. Many of those cases may want to be re-evaluated in the light of this patch. I was going to save that for another day :-) -- To collect all the latest movies, simply place an unprotected ftp server on the Internet, and wait for the disk to fill
Re: [PATCH] no Carp #8 - SelfLoader, Text/Balanced and open.pm
I've applied those of your Carp patches that don't effect dual-homed modules (as determined by 'CPAN' = 1 in Porting/Maintainers.pl). Since it isn't fixing critial bugs, I'm assuming its up to the authors to decide. (And I've finally been won round to the idea that it's worthwhile avoiding use Carp in small, common modules). Change #25052 not applied: Subject: [PATCH] Make Time::Local to load Carp only when nec. Subject: [PATCH] Put Carp into the Tarpit (No Carp #2 - Archive::Tar) Subject: [PATCH] no Carp! #3 - Attribute::Handlers applied: Subject: [PATCH] No Carp #4 AutoSplit.pm Subject: [PATCH] no Carp #5 (File::Path) Subject: [PATCH] no Carp #7 - charnames.pm partly appplied: Subject: [PATCH] no Carp #6 (File::Compare, File::Copy, File::Temp) except File::Temp Subject: [PATCH] no Carp #8 - SelfLoader, Text/Balanced and open.pm except Text/Balanced Dave. -- The Enterprise is involved in a bizarre time-warp experience which is in some way unconnected with the Late 20th Century. -- Things That Never Happen in Star Trek #14
Re: [perl #36450] Lvalue sub fails under debugger
On Sat, Jul 02, 2005 at 10:03:42AM -, houstorx @ rpc142. cs. man. ac. uk
wrote:
Lvalue functions don't work properly when running under the
debugger (perl -d). For example, the following code:
my $x = 'badbad';
sub x :lvalue {$x}
x = good;
print The value of \$x is: $x\n;
prints 'The value of $x is: badbad' when you run it with the
debugger. This happens with every version of perl that I've
tested, including 5.8.6 and 5.9.2.
The reason is that when running under the debugger, all function calls are
wrapped by a call to BD::sub, which does (in outline)
if (wantarray)
@res = $sub;
...
@res;
}
else {
$res = $sub;
...
$res;
}
and of course that blows away the lvalue-ness of the value returned by the
sub.
Can't see an easy way op fixing it.
--
Fire extinguisher (n) a device for holding open fire doors.
Re: Date::Parse (Time::Local?) choking on years between 1956-1938 and wrong below, on FC4/5.8.6
On Fri, Jul 01, 2005 at 05:12:41PM -0400, Scott R. Godin wrote:
5:10pm {638} localhost:/home/webadmin/$ cat mydate
#!/usr/bin/perl -l
use Date::Parse qw/str2time/;
my $d = $ARGV[0];
my $utime = str2time(01/01/$d);
print $utime\t, scalar localtime $utime;
5:10pm {639} localhost:/home/webadmin/$ ./mydate 1956
-441831600 Sun Jan 1 00:00:00 1956
Times on UNIX are usually stored as seconds since 1970, so library
functions which deal with times as numbers are unlikely to correctly
handle dates before 1970 (or after 2037 for 32-bit systems).
--
You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad.
-- Monty Python - Finland
Re: [perl #36427] With long chains of references both Storable and Data::Dumper cause perl to fail
On Wed, Jun 29, 2005 at 09:46:33PM -, kynn jones wrote: With an argument greater than some system-dependent critical size, the script causes perl to segfault: use strict; use warnings; my $size = shift; my $x = []; $x = [ $x ] for 1..$size; require Storable; Storable::store( \$x, '/tmp/$0.$$' ) or die; It's the stack being trashed due to excessive recursion. No real way to fix it short of rewriting Storable to be iterative rather than recursive. The workaround is to increase the stack size available to the process with 'uname -s' -- In defeat, indomitable; in victory, insufferable -- Churchill on Montgomery
Re: [PATCH] We're going round in circles with pp_sys.c
On Fri, Jul 01, 2005 at 02:00:52PM +0100, Steve Hay wrote:
This is caused by the following hunk of change 24997:
@@ -2767,7 +2768,7 @@
dVAR; dSP;/* Make POPBLOCK work. */
PERL_CONTEXT *cx;
SV **newsp;
-I32 gimme = 0; /* SUSPECT - INITIALZE TO WHAT? NI-S */
+I32 gimme;
I32 optype;
OP dummy;
OP *rop;
Should I put that initialization back to silence the warning, or is
there a better fix?
Looks like Dave just did it in change 25035 :-)
Ah, I should have been paying attention. That function is only used to
compile /(?{...})/ code, and is generally broken anyway. I hope to blow it
out of the water one day.
--
Nothing ventured, nothing lost.
