| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
with a NULL subaddr. Fix that, and stop it happening again.
p4raw-id: //depot/perl@17763
|
|
|
|
|
| |
Message-id: <20020806200510.GC31473@ool-18b93024.dyn.optonline.net>
p4raw-id: //depot/perl@17725
|
|
|
|
|
| |
Message-ID: <14963.32943.102669.67625@soda.csua.berkeley.edu>
p4raw-id: //depot/perl@17717
|
|
|
|
|
| |
Message-id: <20020802234421.11c62fe6.rgarciasuarez@free.fr>
p4raw-id: //depot/perl@17699
|
|
|
|
|
|
| |
From: "Brent Dax" <brentdax@cpan.org>
Message-id: <000001c234a1$d1ca72c0$6501a8c0@deepblue>
p4raw-id: //depot/perl@17682
|
|
|
|
|
| |
Message-Id: <184F11EC-9335-11D6-8F80-000393414688@dolphin-services.de>
p4raw-id: //depot/perl@17457
|
|
|
|
|
|
|
| |
outside the sub
Message-Id: <200207081600.g68G0Xw07553@crypt.compulink.co.uk>
p4raw-id: //depot/perl@17423
|
|
|
|
|
|
|
|
|
| |
introduce the test case of [ID 20020623.009]. Once upon a
time #13474 introduced evil coredumps, but now things seem
to be better (tried both with and without ithreads).
p4raw-id: //depot/perl@17407
p4raw-edited: from //depot/maint-5.6/perl@17406 'ignore' op.c
(@14778..)
|
|
|
|
|
|
|
| |
outside the sub
Message-ID: <200206271058.g5RAwvE29057@crypt.compulink.co.uk>
p4raw-id: //depot/perl@17369
|
|
|
| |
p4raw-id: //depot/perl@17251
|
|
|
|
|
|
|
|
|
| |
char" but old code using just a "char" doesn't need changes.
(The change is using a temporary pointer instead of a direct
cast to unsigned char* which would blindly cast anything,
not just char pointers.) (The problem arose in MacOS Classic,
as seen by Pudge, the cure by Nicholas Clark.)
p4raw-id: //depot/perl@16656
|
|
|
| |
p4raw-id: //depot/perl@16547
|
|
|
|
|
|
| |
and valgrind claims that the savepvn() in utilize() leaks in e.g.
lib/blib.t.
p4raw-id: //depot/perl@16237
|
|
|
|
|
| |
op->op_targ
p4raw-id: //depot/perl@16180
|
|
|
|
|
|
| |
change is from change#12026)
p4raw-link: @12026 on //depot/maint-5.6/perl: ff42b73b40f5a895aef4bed81c794f468e0609bc
p4raw-id: //depot/perl@16048
|
|
|
|
|
| |
Message-ID: <20020401182201.21189.qmail@plover.com>
p4raw-id: //depot/perl@15663
|
|
|
|
|
| |
Message-Id: <200203290552.AAA47443@leggy.zk3.dec.com>
p4raw-id: //depot/perl@15592
|
|
|
|
|
| |
Message-Id: <200203280152.UAA415562@leggy.zk3.dec.com>
p4raw-id: //depot/perl@15565
|
|
|
|
|
| |
(Is there an approved way of testing "is this an unop"?)
p4raw-id: //depot/perl@15439
|
|
|
|
|
|
| |
for unops (via newUNOP() and ck_eof()).
(analysis okay, patch bad: see #15439)
p4raw-id: //depot/perl@15434
|
|
|
| |
p4raw-id: //depot/perl@15292
|
|
|
|
|
|
| |
From: "Paul Marquess" <paul_marquess@yahoo.co.uk>
Message-ID: <AIEAJICLCBDNAAOLLOKLMEEGDPAA.paul_marquess@yahoo.co.uk>
p4raw-id: //depot/perl@15155
|
|
|
| |
p4raw-id: //depot/perl@15147
|
|
|
|
|
|
|
|
| |
that makes the standard filehandles to talk in
encodings. This change set off a weird warning
from op.c, though: disabled it now until someone
who knows what it is about comes along.
p4raw-id: //depot/perl@15146
|
|
|
|
|
|
| |
From: "Paul Marquess" <paul_marquess@yahoo.co.uk>
Message-ID: <AIEAJICLCBDNAAOLLOKLCEKGDOAA.paul_marquess@yahoo.co.uk>
p4raw-id: //depot/perl@15003
|
|
|
|
|
|
| |
The problem exists, but the cure, in which ever form
it will be, needs to be something more subtle.
p4raw-id: //depot/perl@14962
|
|
|
| |
p4raw-id: //depot/perl@14949
|
|
|
|
|
|
| |
now __ANON__::__ANON__ (should help for mod_perl breakage
since #12251)
p4raw-id: //depot/perl@14899
|
|
|
|
|
|
|
|
|
|
|
| |
constant folding on the range operator had the effect of disabling
peephole optimizations in all the siblings of the range OP; the
effect of this was that barewords could escape strictures when
they were hiding in such places
p4raw-link: @14778 on //depot/maint-5.6/perl: 0ef6625236721d79a74c662bb0d14b11d0d775c2
p4raw-id: //depot/perl@14791
p4raw-integrated: from //depot/maint-5.6/perl@14790 'merge in' op.c
(@14439..)
|
|
|
|
|
| |
Message-ID: <20020209210013.GG410@Bagpuss.unfortu.net>
p4raw-id: //depot/perl@14613
|
|
|
|
|
| |
(the latter came into bleadperl as part of #14433).
p4raw-id: //depot/perl@14580
|
|
|
|
|
| |
Should really be looked at by someone that knows about pads.
p4raw-id: //depot/perlio@14431
|
|
|
|
|
|
|
| |
anon sub leakage.
p4raw-id: //depot/perl@14418
p4raw-edited: from //depot/maint-5.6/perl@14417 'ignore' op.c
(@13478..)
|
|
|
| |
p4raw-id: //depot/perl@14391
|
|
|
|
|
|
| |
e.g. -Duse64bitint on a 32-bit platform.
Now uses I32 for use-count and is more careful with its casts.
p4raw-id: //depot/perlio@14281
|
|
|
| |
p4raw-id: //depot/perlio@14269
|
|
|
| |
p4raw-id: //depot/perlio@14267
|
|
|
|
|
|
|
|
|
|
|
|
| |
Need to use CopXXXXX macros everywhere and add CopSTASH_free
Add new scope type and add support for it to scope.c and scope stack
dup-er in sv.c. Add savesharedpv().
Also zealous version of Win32's vmem.h to catch all the abuses.
With this t/op/fork.t passes even with zealous checking and
checker is point a finger at various threads/shared issues.
PL_curcop->cop_io is still an issue.
p4raw-id: //depot/perlio@14259
|
|
|
|
|
|
|
| |
- moved the statics to intrpvar.h
- implemented Slab_Free()
- uses PerlMemShared (for now) if distinction exists.
p4raw-id: //depot/perlio@14250
|
|
|
|
|
| |
Message-Id: <200201081917.g08JHoW15789@crypt.compulink.co.uk>
p4raw-id: //depot/perl@14139
|
|
|
|
|
| |
Message-ID: <m38zb9c7gi.fsf@anima.de>
p4raw-id: //depot/perl@14135
|
|
|
| |
p4raw-id: //depot/perlio@14088
|
|
|
|
|
| |
Message-ID: <20020104233519.A1850@rafael>
p4raw-id: //depot/perl@14082
|
|
|
| |
p4raw-id: //depot/perl@14041
|
|
|
| |
p4raw-id: //depot/perl@14020
|
|
|
|
|
| |
Message-Id: <3C334558.3906.19CB98D@localhost>
p4raw-id: //depot/perl@14016
|
|
|
|
|
| |
Message-ID: <m3bsgnajws.fsf@anima.de>
p4raw-id: //depot/perl@13882
|
|
|
|
|
| |
Message-ID: <20011224231448.25826.qmail@plover.com>
p4raw-id: //depot/perl@13881
|
|
|
| |
p4raw-id: //depot/perl@13843
|
|
|
|
|
|
| |
U+...FFFE, U+...FFFF, and characters beyond U+10FFFF
(the Unicode maximum code point) warnable offenses.
p4raw-id: //depot/perl@13823
|