| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This is a regression in 5.10 caused by change 23966/08ca2aa38a29,
which added a bit of faulty logic. It was treating U* in the middle of
a pack template as equivalent to U0, if the input string was empty.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[perl #86534]
When using 80-bit extended precision floats, gcc-generated code
can sometimes copy 10 bytes and sometimes 12. This can lead to 2 random
bytes something appearing in the output of pack('F') and pack('D').
Work around this by using sv_2nv() rather than SvNV()
(which expands to (SvNOK(sv) ? SvNVX(sv) : sv_2nv(sv) )
The basic issue is that the NV return value of a function is returned
in a floating point register, which is then written to memory as 10 bytes,
whereas a direct assignment, e.g. NV nv1 = nv2, is done by a 12-byte
memory copy.
However, when the sv_2nv() function is called as part of the ?:
expression, its returned value is written as *10* bytes to a temp location
on the stack, which is then copied as a *12* byte value to its final
destination, picking up 2 bytes of random data from the stack, which then
appears in the output of pack(), and ultimately leads to a test failure.
|
|
|
|
|
|
|
|
|
| |
# 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>
|
| |
|
|
|
|
|
|
|
| |
split() would crash because the third item on the stack wasn't the
regular expression it expected. unpack("%2H", ...) would return both
the unpacked result and the checksum on the stack, similarly for
unpack("%2u", ...).
|
|
|
|
|
|
|
|
| |
When memcpy() is used on a long double pointer with gcc 4.4 in some
cases it seems to treat it as a long double assignment, copying only
the first 12 bytes. Use unions so the types we're copying into the
pack output or from the unpack input are unsigned char[], to avoid the
apparent bug.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Replace ckWARN{,2,3,4}() && Perl_warner() with it, which trades reduced code
size (about 0.2%), for 1 more function call if warnings are not enabled.
However, if we're now in the L1 or L2 cache when we weren't previously, that's
still going to be a speed win.
|
| |
|
| |
|
|
|
|
|
|
| |
This patch only taints for pack('a'/'A') which was the original bug. I
guess the previous behaviour (pre-5.10.0) tainted on all tainted input.
That more general behaviour may be recoverable - not sure what we want.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(The table is 256 bytes; the run-time initialisation code is larger than this!)
Adapt generate_uudmap.c to generate the initalisation block for PL_bitcount,
writing the code to bitcount.h, using the same approach as uudmap.h.
To preserve binary compatibility:
for MULTIPLICITY:
keep Ibitcount in the interpreter structure, but remove all the macros that
access it. PL_bitcount is a new symbol in the object file, which won't clash
with anything as that name wasn't used before.
otherwise:
keep PL_bitcount as a char *, but initialise it at compile time to a new
constant array PL_bitcount array. Remove the code that attempts to Safefree()
it at interpreter destruction time.
|
|
|
|
|
|
| |
Message-ID: <25940.1225611819@chthon>
Date: Sun, 02 Nov 2008 01:43:39 -0600
p4raw-id: //depot/perl@34698
|
|
|
| |
p4raw-id: //depot/perl@34653
|
|
|
| |
p4raw-id: //depot/perl@34585
|
|
|
|
|
|
|
|
|
|
|
|
| |
ability to create landmines that will explode under someone in the
future when they upgrade their compiler to one with better
optimisation. We've already done this at least twice.
(Yes, some of the assertions are after code that would already have
SEGVd because it already deferences a pointer, but they are put in
to make it easier to automate checking that each and every case is
covered.)
Add a tool, checkARGS_ASSERT.pl, to check that every case is covered.
p4raw-id: //depot/perl@33291
|
|
|
|
|
|
|
|
| |
From: "Green, Paul" <Paul.Green@stratus.com>
Message-ID: <F5F42E77A43DD944B6D664B00A5401CB037149FF@EXNA.corp.stratus.com>
Includes a fix to the patch to ext/Time/HiRes/Makefile.PL
p4raw-id: //depot/perl@33259
|
|
|
|
|
|
| |
resulting in garbage on the stack, which could manifest as a SEGV
(Bug 50256)
p4raw-id: //depot/perl@33239
|
|
|
|
|
|
| |
and mortalizing them. Use these macros where possible. And also
mX?PUSH[inpu] where possible.
p4raw-id: //depot/perl@32821
|
|
|
|
|
|
| |
the flags. Move its implementation just ahead of sv_2mortal()'s for
CPU cache locality. Refactor all code that can be to use this.
p4raw-id: //depot/perl@32818
|
|
|
|
|
|
|
|
|
|
| |
flag bits. Right now the only flag bit is SVf_UTF8, which will call
SvUTF8_on() on the new SV for you. Provide a wrapper newSVpvn_utf8(),
which takes a boolean, and passes in SVf_UTF8 if that is true.
Refactor the core to use it where possible. It makes the source code
clearer and smaller, but seems to be swings and roundabouts on object
code size.
p4raw-id: //depot/perl@32807
|
|
|
| |
p4raw-id: //depot/perl@32237
|
|
|
|
|
| |
Message-ID: <20070412064153.GA22475@schmorp.de>
p4raw-id: //depot/perl@31194
|
|
|
|
|
|
|
| |
code, and instead use it to generate a header at perl build time.
By removing uudmap from the interpreter structure we save 256 bytes
per child thread.
p4raw-id: //depot/perl@31059
|
|
|
|
|
| |
perl API functions called don't need a NUL terminated string.
p4raw-id: //depot/perl@31038
|
|
|
|
|
|
| |
declarations onto the same line as the return type, to make checking
this easier.
p4raw-id: //depot/perl@30846
|
|
|
|
|
|
| |
From: dgay@acm.org (via RT) <perlbug-followup@perl.org>
Message-ID: <rt-3.5.HEAD-31259-1159489837-428.40427-75-0@perl.org>
p4raw-id: //depot/perl@28917
|
|
|
|
|
|
| |
From: "Robin Barker" <Robin.Barker@npl.co.uk>
Message-ID: <2C2E01334A940D4792B3E115F95B7226120A21@exchsvr1.npl.ad.local>
p4raw-id: //depot/perl@28786
|
|
|
|
|
| |
Message-ID: <44D2E203.5050201@iki.fi>
p4raw-id: //depot/perl@28662
|
|
|
|
|
| |
http://www.nntp.perl.org/group/perl.daily-build.reports/39733
p4raw-id: //depot/perl@28626
|
|
|
|
|
| |
Message-ID: <20060521050240.GA21051@petdance.com>
p4raw-id: //depot/perl@28289
|
|
|
|
|
| |
Message-Id: <20060515223901.F3B0.BQW10602@nifty.com>
p4raw-id: //depot/perl@28209
|
|
|
|
|
| |
Message-ID: <20060512052123.GA21648@petdance.com>
p4raw-id: //depot/perl@28180
|
|
|
| |
p4raw-id: //depot/perl@28032
|
|
|
| |
p4raw-id: //depot/perl@28031
|
|
|
|
|
| |
overloading.
p4raw-id: //depot/perl@28030
|
|
|
|
|
| |
Message-ID: <44527402.8000506@gmail.com>
p4raw-id: //depot/perl@28008
|
|
|
| |
p4raw-id: //depot/perl@27956
|
|
|
|
|
|
| |
Message-ID: <20060203152449.GI12591@accognoscere.homeunix.org>
Date: Fri, 3 Feb 2006 16:24:49 +0100
p4raw-id: //depot/perl@27065
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Message-ID: <43BE7C4D.1010302@gmail.com>
p4raw-id: //depot/perl@26675
|
|
|
| |
p4raw-id: //depot/perl@26652
|
|
|
|
|
| |
Gets rid of many hardcoded string lengths.
p4raw-id: //depot/perl@26641
|
|
|
|
|
| |
Message-ID: <017a01c60d83$5dc73110$2217a8c0@candy>
p4raw-id: //depot/perl@26549
|
|
|
|
|
| |
Message-ID: <20051205194613.GB7791@petdance.com>
p4raw-id: //depot/perl@26281
|
|
|
|
|
| |
Message-ID: <20051201202451.GI22713@petdance.com>
p4raw-id: //depot/perl@26242
|
|
|
|
|
| |
when pack warnings were not enabled
p4raw-id: //depot/perl@26130
|
|
|
|
|
| |
Message-ID: <20051111044700.GA24161@petdance.com>
p4raw-id: //depot/perl@26082
|
|
|
|
|
| |
Message-ID: <lracgj1bv0.fsf@caliper.activestate.com>
p4raw-id: //depot/perl@26032
|
|
|
|
|
|
|
|
| |
Specifically, this silences the warnings from the following smoke:
http://www.nntp.perl.org/group/perl.daily-build.reports/32258
(Hmm. Looks like you need to decode the base64 yourself before you
can read that.)
p4raw-id: //depot/perl@25779
|