| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Magic with a NULL vtable is equivalent to magic with a vtable of all 0s.
On CPAN, only Apache::Peek's code for 5.005 is referencing it.
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81904]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81904 >
Signed-off-by: Abigail <abigail@abigail.be>
|
|
|
|
|
|
| |
The previous macro generated over .5K of object code. This is in every shared
object, and is only called once. Hence this change increases the perl binary
by about .5K (once), to save .5K for every XS module loaded.
|
|
|
|
|
|
| |
The macro expansion generates over 1K of object code. This is in every shared
object, and is only called once. Hence this change increases the perl binary
by about 1K (once), to save 1K for every XS module loaded.
|
|
|
|
| |
It should not be FALSE, because it's a bitmap, not a boolean.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds PL_apiversion, allowing the API version of a running interpreter to be
introspected. It is used in the new XS_APIVERSION_BOOTCHECK macro, which is
added to the _boot function of every XS module, to compare it against the API
version the module has been compiled against. If the versions do not match, an
exception is thrown.
This doesn't fully prevent binary incompatible extensions to be loaded. It
merely compares PERL_API_* between compile- and runtime, and does not attempt to
solve the problem of identifying binary incompatible perls with the same API
version (i.e. the same perl version configured with and without DEBUGGING).
|
|
|
|
|
|
|
|
|
| |
The SV holding XS_VERSION, and the version object created from it were
leaked. Also, if the version from perl space wasn't a version object already,
the one that got created leaked.
Additionally, in case of an error, the two SVs returned by vstringify were
leaked.
|
| |
|
|
|
|
|
| |
See also http://rt.cpan.org/Public/Bug/Display.html?id=55049
with workaround in http://code.google.com/p/perl-devel-nytprof/source/detail?r=1168
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
Using the attached patch to the blead source (as of a few hours ago), I can
build perl with the following OS/compiler/make combos.
On 32-bit XP:
MSVC++ 7.0 / dmake (uses win32/makefile.mk)
MSVC++ 7.0 / nmake (uses win32/Makefile)
Borland C++ 5.5.1 / dmake
mingw.org's gcc-4.3.0 / dmake
mingw.org's gcc-3.4.5 / dmake
mingw-w64.sf's 32-bit gcc-4.4.3 / dmake
(There's a bug with that last compiler on XP.
The perl it builds on XP hangs on XP, but runs ok if copied across to Vista.
I think this is unrelated to the patches - probably even unrelated to perl.
Without these patches perl will not even build using that last compiler.)
On 64-bit Vista:
32-bit MSVC++ 7.0 / nmake (uses win32/Makefile)
32-bit MSVC++ 7.0 / dmake (uses win32/makfile.mk)
32-bit Borland C++ 5.5.1 / dmake
mingw.org's 32-bit gcc-4.4.0 / dmake
mingw.org's 32-bit gcc-3.4.5 / dmake
mingw-w64.sf's 32-bit gcc-4.4.3 / dmake
mingw-w64.sf's 64-bit gcc-4.4.3 / dmake
mingw-w64.sf's 64-bit x86_64-w64-mingw32-gcc-4.4.3 / dmake
64-bit MicrosoftPlatform SDK for Windows Server 2003 R2 / dmake (uses
win32/makefile.mk)
64-bit MicrosoftPlatform SDK for Windows Server 2003 R2 / nmake (uses
win32/Makefile)
Not all of those builds pass all tests - but where the removal of the
patches still permits perl to build, the same tests still fail. That is,
*nothing* is lost by including these patches - but there are significant
gains.
Each of the above builds was done according to the normal win32
configuration parameters - ie multi-threaded, non debug. No unusual config
settings were applied. (I did build one debug perl on Vista using
mingw-w64.sf's 32-bit gcc-4.4.3 and it built fine.)
Please feel free to apply these patches (with or without modification) -
and, yes, you're more than welcome to blame me if they cause any breakages
;-)
Of course, some of those compilers (Borland, Microsoft, and the compilers
from mingw.org) already build perl *without* having to apply any patches.
It's just the other compilers that need the patches. The purpose of testing
with Borland, Microsoft, and the mingw.org compilers is just to check that
these patches don't break them.
As a final check, I've done a build on my aging linux (mandrake-9.1) box,
gcc-3.2.2. I built with '-des -Duselongdouble -Duse64bitint -Dusedevel'. No
problem with that, either.
If there's additional testing requirements please let me know, and I'll try
to oblige.
I believe the patch applied successfully for me - see below my sig for the
output.
Cheers,
Rob
Rob@desktop2 ~/GIT/blead
$ patch -p0 <blead_diff.diff
patching file dist/threads/threads.xs
patching file handy.h
patching file cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm
patching file op.c
Hunk #1 succeeded at 5774 (offset 47 lines).
patching file pp_pack.c
patching file util.c
Hunk #1 succeeded at 5366 (offset -28 lines).
patching file win32/makefile.mk
patching file win32/perlhost.h
patching file win32/win32.c
patching file win32/win32.h
patching file README.win32
patching file XSUB.h
|
| |
|
|
|
|
|
|
|
|
|
| |
As Nicholas already noted in a FIXME, assigning to DEFSV should
use GvSV instead of GvSVn. This change ensures that, at least
under -DPERL_CORE, DEFSV cannot be assigned to and introduces
a DEFSV_set macro to allow setting DEFSV.
This fixes #53038: map leaks memory.
p4raw-id: //depot/perl@34776
|
|
|
| |
p4raw-id: //depot/perl@34585
|
|
|
| |
p4raw-id: //depot/perl@32820
|
|
|
|
|
|
|
|
|
|
|
|
| |
typedef XS(SwigPerlWrapper);
typedef SwigPerlWrapper *SwigPerlWrapperPtr;
This breaks if XS() includes the 'extern "C"' decoration under C++.
The appended patch provides an XSPROTO() macro that could be used
by SWIG instead.
(Patch from Jan Dubois to fix breakage caused by #28734.)
p4raw-id: //depot/perl@31697
|
|
|
|
|
|
| |
From: "Robert May" <robertmay@cpan.org>
Message-ID: <54bdc7510707211829t67e8b82eo7d8e722e73c6a3b3@mail.gmail.com>
p4raw-id: //depot/perl@31653
|
|
|
|
|
| |
Message-Id: <B46A083E-A133-4D38-9BE8-BE1EB0AAA326@petdance.com>
p4raw-id: //depot/perl@31270
|
|
|
|
|
| |
Message-ID: <prol131i8b27re246alnhmem4mj13fcl2b@4ax.com>
p4raw-id: //depot/perl@30879
|
|
|
|
|
|
| |
files that generate .h files, so they'll be ready
next time.
p4raw-id: //depot/perl@29695
|
|
|
|
|
|
|
|
|
| |
Subject: [PATCH] Cleanup SVf arguments (2nd try)
Message-ID: <20070101201613.4120d9ef@r2d2>
Introduce an SVfARG() macro for %SVf (%-p here) arguments to
perl's printf
p4raw-id: //depot/perl@29687
|
|
|
|
|
|
|
|
| |
Subject: [PATCH] Cleanup SVf arguments (2nd try)
Message-ID: <20070101201613.4120d9ef@r2d2>
Adds (void*) casts to %-p and %p printf arguments
p4raw-id: //depot/perl@29686
|
|
|
| |
p4raw-id: //depot/perl@29684
|
|
|
|
|
| |
most efficient idea.
p4raw-id: //depot/perl@29042
|
|
|
| |
p4raw-id: //depot/perl@28966
|
|
|
|
|
| |
[And these are function pointers, so they're not NULL :-)]
p4raw-id: //depot/perl@28962
|
|
|
|
|
| |
Message-ID: <9b18b3110610061016x5ddce965u30d9a821f632d450@mail.gmail.com>
p4raw-id: //depot/perl@28957
|
|
|
|
|
| |
(See: http://www.nntp.perl.org/group/perl.daily-build.reports/40283)
p4raw-id: //depot/perl@28759
|
|
|
|
|
| |
Message-ID: <44E49649.9090307@iki.fi>
p4raw-id: //depot/perl@28734
|
|
|
|
|
|
|
| |
storage to newXS() seemingly forever. This involves creating
newXS_flags(), with the first flag being "arrange to copy the
filename and free it at the right time".
p4raw-id: //depot/perl@28063
|
|
|
|
|
|
| |
from I32 to PADOFFSET, which is more correct (and fixes
a warning in Devel::PPPort).
p4raw-id: //depot/perl@27968
|
|
|
| |
p4raw-id: //depot/perl@27696
|
|
|
|
|
|
|
| |
and default definitions for the 2 variables. (Which will save a lot of
conditional complilation, by instead letting the C compiler optimiser
remove dead code.)
p4raw-id: //depot/perl@27408
|
|
|
|
|
|
| |
Instead remove &PL_vtbl_glob from globvar.sym.
p4raw-link: @27295 on //depot/perl: 3476b56103cbe13508b1fd6b46ae7b9cb6e0f7ed
p4raw-id: //depot/perl@27296
|
|
|
|
|
| |
p4raw-link: @27289 on //depot/perl: c0c446747ad6c5bde53bc8415ca16ef77f6320f2
p4raw-id: //depot/perl@27295
|
|
|
|
|
|
| |
SVpad_OUR with macros SvPAD_TYPED(), SvPAD_OUR() etc, to abstract
away the flags bits acutally used to store this information.
p4raw-id: //depot/perl@27294
|
|
|
|
|
| |
Message-ID: <20060215125148.GA12535@brugman.iloquent.nl>
p4raw-id: //depot/perl@27203
|
|
|
|
|
| |
Message-ID: <20060202093849.GD12591@accognoscere.homeunix.org>
p4raw-id: //depot/perl@27054
|
|
|
| |
p4raw-id: //depot/perl@26176
|
|
|
|
|
| |
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24E7A611@esebe105.NOE.Nokia.com>
p4raw-id: //depot/perl@25778
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@ActiveState.com>
Message-Id: <200509270419.j8R4JtVw026876@smtp3.ActiveState.com>
p4raw-id: //depot/perl@25613
|
|
|
| |
p4raw-id: //depot/perl@25254
|
|
|
|
|
| |
Message-ID: <20050620152237.GA5032@petdance.com>
p4raw-id: //depot/perl@24913
|
|
|
|
|
| |
Message-ID: <20050616143521.GB22188@petdance.com>
p4raw-id: //depot/perl@24873
|
|
|
| |
p4raw-id: //depot/perl@24757
|
|
|
| |
p4raw-id: //depot/perl@24724
|
|
|
|
|
| |
Message-ID: <20050519173256.GA29039@petdance.com>
p4raw-id: //depot/perl@24508
|
|
|
|
|
| |
Message-ID: <20050516151353.GA25387@petdance.com>
p4raw-id: //depot/perl@24489
|
|
|
|
|
|
| |
From: Sergey Skvortsov (via RT) <perlbug-followup@perl.org>
Message-ID: <rt-3.0.11-33809-105714.16.4209917806492@perl.org>
p4raw-id: //depot/perl@24372
|
|
|
|
|
| |
Message-ID: <20050422223947.GA4681@petdance.com>
p4raw-id: //depot/perl@24333
|
|
|
|
|
| |
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2453D653@esebe105.NOE.Nokia.com>
p4raw-id: //depot/perl@24271
|