| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
The dual-life dists affected use Devel::PPPort, so can safely use
newSVpvs() even though it wasn't added until Perl v5.8.9.
|
|
|
|
|
|
| |
Calls to Perl_do_openn() all have at least 2 unused arguments which clutter
the code and hinder easy understanding. Perl_do_open6() and
Perl_do_open_raw() each only do one job, so don't have the dead arguments.
|
|
|
|
|
|
| |
av_tindex is a more clearly named synonym for av_len, available starting
in v5.18. This changes the core uses to it, including modules in /ext,
which are not dual-lifed.
|
|
|
|
|
| |
This was added in 5.5/5.6 as a backwards-compatibility measure
when taint was extended to happen in more places.
|
|
|
|
| |
Bump $VERSION for os2/OS2/OS2-Process/Process.pm.
|
|
|
|
|
| |
These were all uncovered by the new Pod::Checker, not yet in core.
Fixing these will speed up debugging the new Checker.
|
|
|
|
|
|
|
| |
This finishes the removal of register declarations started by
eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in
function parameter declarations, and didn't include things in dist, ext,
and lib, which this does include
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By defining NO_TAINT_SUPPORT, all the various checks that perl does for
tainting become no-ops. It's not an entirely complete change: it doesn't
attempt to remove the taint-related interpreter variables, but instead
virtually eliminates access to it.
Why, you ask? Because it appears to speed up perl's run-time
significantly by avoiding various "are we running under taint" checks
and the like.
This change is not in a state to go into blead yet. The actual way I
implemented it might raise some (valid) objections. Basically, I
replaced all uses of the global taint variables (but not PL_taint_warn!)
with an extra layer of get/set macros (TAINT_get/TAINTING_get).
Furthermore, the change is not complete:
- PL_taint_warn would likely deserve the same treatment.
- Obviously, tests fail. We have tests for -t/-T
- Right now, I added a Perl warn() on startup when -t/-T are detected
but the perl was not compiled support it. It might be argued that it
should be silently ignored! Needs some thinking.
- Code quality concerns - needs review.
- Configure support required.
- Needs thinking: How does this tie in with CPAN XS modules that use
PL_taint and friends? It's easy to backport the new macros via PPPort,
but that doesn't magically change all code out there. Might be
harmless, though, because whenever you're running under
NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false.
Thus, the only CPAN code that SHOULD be adversely affected is code
that changes taint state.
|
|
|
|
|
|
| |
Commit 78ed4cf4d6 undid the accidental effect of eb578fdb55 on OS2::REXX
but forgot to revert the accompanying VERSION bump, which is not otherwise
required since nothing else has changed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most register declarations in C code (and accompanying
documentation) in the Perl core. Retained are those in the ext
directory, Configure, and those that are associated with assembly
language.
See:
http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c
which says, in part:
There is no good example of register usage when using modern compilers
(read: last 10+ years) because it almost never does any good and can do
some bad. When you use register, you are telling the compiler "I know
how to optimize my code better than you do" which is almost never the
case. One of three things can happen when you use register:
The compiler ignores it, this is most likely. In this case the only
harm is that you cannot take the address of the variable in the
code.
The compiler honors your request and as a result the code runs slower.
The compiler honors your request and the code runs faster, this is the least likely scenario.
Even if one compiler produces better code when you use register, there
is no reason to believe another will do the same. If you have some
critical code that the compiler is not optimizing well enough your best
bet is probably to use assembler for that part anyway but of course do
the appropriate profiling to verify the generated code is really a
problem first.
|
|
|
|
|
| |
The subdirectory containing the port specific files was purged when 5.000
was released, but changes made to other files were not removed.
|
| |
|
| |
|
| |
|
|
|
|
| |
./perl -Ilib Porting/cmpVERSION.pl -xd . v5.13.8
|
| |
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81900]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81900 >
Signed-off-by: Abigail <abigail@abigail.be>
|
|
|
|
| |
Signed-off-by: Abigail <abigail@abigail.be>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I don't have OS/2, so I can't test this, but the code in Configure will assume
flat directories, because ext/File-Glob is present, and hence not search
recursively and not find the OS/2 extensions if they are copied into ext/OS2/*
I believe that without this change OS/2 will not have been building since the
change to flattened ext. This change may not be sufficient to get OS/2
building again, but it is in the right direction.
|
|
|
|
| |
since 5.005
|
|
|
|
|
| |
and hence the 'create' argument is actually 'flags'. Fix core code and
documentation that used TRUE or FALSE to use 0 or GV_ADD.
|
|
|
|
|
|
| |
Message-ID: <25940.1225611819@chthon>
Date: Sun, 02 Nov 2008 01:43:39 -0600
p4raw-id: //depot/perl@34698
|
|
|
|
|
|
|
|
|
|
| |
since 5.8.8, ready for merging into maint-5.8 prior to 5.8.9.
(Many (all?) of these should really have been changed prior to
5.10.0, but better late than never.)
Also modify cmpVERSION.pl to skip uninstalled test modules whose
VERSIONs don't really matter.
p4raw-id: //depot/perl@34365
|
|
|
|
|
|
|
| |
Porting/cmpVERSION.pl reports differ from the 5.10.0 release.
All the rest of the differences would seem to be dual-life. :-(
p4raw-id: //depot/perl@33623
|
|
|
|
|
|
|
|
| |
Message-ID: <477D28BD.5060801@profvince.com>
Mortalize SVs that are being pushed on the stack.
Try to use specialized macros for pushing mortals.
p4raw-id: //depot/perl@32822
|
|
|
|
|
|
| |
system specific directories. I think I've chainsawed all of them now,
but I can't guarantee that it compiles anywhere from win32.
p4raw-id: //depot/perl@32713
|
|
|
| |
p4raw-id: //depot/perl@32704
|
|
|
| |
p4raw-id: //depot/perl@31970
|
|
|
|
|
| |
Message-ID: <20061218084524.GA14866@powdermilk.math.berkeley.edu>
p4raw-id: //depot/perl@29580
|
|
|
|
|
| |
Message-ID: <20061214023222.GA29084@powdermilk.math.berkeley.edu>
p4raw-id: //depot/perl@29578
|
|
|
|
|
| |
Message-ID: <20061210003341.GA14200@powdermilk.math.berkeley.edu>
p4raw-id: //depot/perl@29497
|
|
|
|
|
| |
in */*ish.h headers.
p4raw-id: //depot/perl@29077
|
|
|
|
|
|
|
|
| |
Keep NEWSV() itself for backwards-compatibility outside of the core,
but don't advertise it any more.
(cf. change #25101).
p4raw-link: @25101 on //depot/perl: a02a5408b2f199007c4dcb74559cc79066307ada
p4raw-id: //depot/perl@26901
|
|
|
| |
p4raw-id: //depot/perl@26804
|
|
|
| |
p4raw-id: //depot/perl@26694
|
|
|
| |
p4raw-id: //depot/perl@25844
|
|
|
|
|
|
| |
From: "Piotr Fusik" <pfusik@op.pl>
Message-ID: <001401c595bd$dccb5d80$0bd34dd5@piec>
p4raw-id: //depot/perl@25261
|
|
|
|
|
|
|
|
| |
Message-ID: <42CC3CE9.5050606@divsol.com>
(reverted all dual-lived modules since they must work with older
perls too so must wait for a new Devel::PPPort)
p4raw-id: //depot/perl@25101
|
|
|
|
|
| |
Message-ID: <20031218221029.GA7898@math.berkeley.edu>
p4raw-id: //depot/perl@22032
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Date: Tue, 4 Nov 2003 20:10:16 -0800
Message-ID: <20031105041016.GA2639@math.berkeley.edu>
and part of
Subject: [PATCH 5.8.2 @21574] make install: PREFIX and DESTDIR
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Date: Tue, 4 Nov 2003 20:18:37 -0800
Message-ID: <20031105041836.GA2649@math.berkeley.edu>
(I've left out the PREFIX part for now)
p4raw-id: //depot/perl@21697
|
|
|
|
|
| |
Message-ID: <20031107072618.GA4370@math.berkeley.edu>
p4raw-id: //depot/perl@21677
|
|
|
|
|
| |
Message-ID: <20031104042044.GA1682@math.berkeley.edu>
p4raw-id: //depot/perl@21651
|
|
|
|
|
| |
Message-ID: <20031029220017.GA26384@math.berkeley.edu>
p4raw-id: //depot/perl@21620
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subject: [PATCH 5.8.1 @21211] sockets broken on OS/2
Date: Thu, 25 Sep 2003 12:09:11 -0700
Message-ID: <20030925190911.GA27028@math.berkeley.edu>
Subject: Re: [PATCH 5.8.1 @21379] tmpfile() broken on OS/2
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Date: Thu, 25 Sep 2003 19:50:45 -0700
Message-ID: <20030926025045.GA27507@math.berkeley.edu>
p4raw-id: //depot/perl@21509
|