summaryrefslogtreecommitdiff
path: root/pp_pack.c
Commit message (Collapse)AuthorAgeFilesLines
* Omnibus removal of register declarationsKarl Williamson2012-08-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* update the editor hints for spaces, not tabsRicardo Signes2012-05-291-2/+2
| | | | | This updates the editor hints in our files for Emacs and vim to request that tabs be inserted as spaces.
* [perl #60204] Unhelpful error message from unpackMarcus Holland-Moritz2012-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Nigel Sandever said: > The error message produced by the following snippets is very unhelpful: > > c:\>perl -wle"print unpack 'v/a*', qq[a]" > '/' must follow a numeric type in unpack at -e line 1. > > c:\>perl -wle"print unpack 'v/a*', ''" > '/' must follow a numeric type in unpack at -e line 1. > > c:\>perl -wle"print unpack 'v/a*', ' '" > '/' must follow a numeric type in unpack at -e line 1. The "problem" is that the data string is too short. But unpack doesn't generate a warning (or croak) in this case for simple patterns: mhx@r2d2 $ perl -MData::Dumper -we'print Dumper([unpack "n", "a"])' $VAR1 = []; So, I'd say your code should just behave in exactly the same way. No warning, no return values.
* pp_pack.c: Use macro instead of its expansionKarl Williamson2012-05-221-2/+2
| | | | There is a macro that means this code; use it.
* Provide as much diagnostic information as possible in "panic: ..." messages.Nicholas Clark2012-01-161-3/+8
| | | | | | | | | | | | | | | The convention is that when the interpreter dies with an internal error, the message starts "panic: ". Historically, many panic messages had been terse fixed strings, which means that the out-of-range values that triggered the panic are lost. Now we try to report these values, as such panics may not be repeatable, and the original error message may be the only diagnostic we get when we try to find the cause. We can't report diagnostics when the panic message is generated by something other than croak(), as we don't have *printf-style format strings. Don't attempt to report values in panics related to *printf buffer overflows, as attempting to format the values to strings may repeat or compound the original error.
* [perl #90160] U* gives ‘U0 mode on an empty string’Father Chrysostomos2011-05-181-1/+1
| | | | | | 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.
* pack test failures with long doubles on x86/gccDavid Mitchell2011-03-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | [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.
* Fix typos (spelling errors) in Perl sources.Peter J. Acklam) (via RT2011-01-071-3/+3
| | | | | | | | | # 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>
* Silence a couple of false positive "may be used uninitialized" gcc warningsVincent Pit2010-05-041-2/+2
|
* RT#73814 - unpack() didn't handle scalar context correctly for %32H and %32uTony Cook2010-04-301-12/+21
| | | | | | | 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", ...).
* Fix for #71506: work around possible gcc bugTony Cook2010-01-191-20/+35
| | | | | | | | 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.
* Add mingw64 supportSisyphus2009-11-091-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add Perl_ck_warner(), which combines Perl_ckwarn() and Perl_warner().Nicholas Clark2009-10-121-32/+26
| | | | | | | 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.
* Normalise 3 fatal pack/unpack error messages to "panic: %s"Nicholas Clark2009-10-121-3/+3
|
* In uni_to_bytes(), fix ckWARN() anomaly.Nicholas Clark2009-10-121-1/+2
|
* Fix for RT #52552.Robin Barker2009-06-231-0/+1
| | | | | | 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.
* Replace run-time on-demand initialisation of PL_bitcount with a constant table.Nicholas Clark2009-05-201-14/+0
| | | | | | | | | | | | | | | | (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.
* PATCH: Large omnibus patch to clean up the JRRT quotesTom Christiansen2008-11-021-0/+2
| | | | | | Message-ID: <25940.1225611819@chthon> Date: Sun, 02 Nov 2008 01:43:39 -0600 p4raw-id: //depot/perl@34698
* Use pvs macros instead of pvn where possible.Marcus Holland-Moritz2008-10-291-1/+1
| | | p4raw-id: //depot/perl@34653
* Update copyright years.Nicholas Clark2008-10-251-2/+2
| | | p4raw-id: //depot/perl@34585
* assert() that every NN argument is not NULL. Otherwise we have theNicholas Clark2008-02-121-1/+34
| | | | | | | | | | | | 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
* RE: Perl @ 33218 (Stratus VOS patches)Paul Green2008-02-081-0/+6
| | | | | | | | 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
* in unpack, () groups in scalar context were still returning a list,Nicholas Clark2008-02-061-0/+1
| | | | | | resulting in garbage on the stack, which could manifest as a SEGV (Bug 50256) p4raw-id: //depot/perl@33239
* Add macros mPUSHs() and mXPUSHs() for pushing SVs on the stackMarcus Holland-Moritz2008-01-041-32/+32
| | | | | | and mortalizing them. Use these macros where possible. And also mX?PUSH[inpu] where possible. p4raw-id: //depot/perl@32821
* Extend newSVpvn_flags() to also call sv_2mortal() if SVs_TEMP is set inNicholas Clark2008-01-031-3/+3
| | | | | | 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
* Add a new function newSVpvn_flags(), which takes a third parameter ofNicholas Clark2008-01-021-3/+3
| | | | | | | | | | 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
* Fix up copyright years for files modified in 2007.Nicholas Clark2007-11-071-1/+1
| | | p4raw-id: //depot/perl@32237
* Re: Compress::Zlib, pack "C" and utf-8 [PATCH]Marc Lehmann2007-05-101-18/+26
| | | | | Message-ID: <20070412064153.GA22475@schmorp.de> p4raw-id: //depot/perl@31194
* Make PL_uudmap a constant global. Remove the run time initialisationNicholas Clark2007-04-241-16/+0
| | | | | | | 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
* Remove the unnecessary allocation of and assignment to hunk[3], as theNicholas Clark2007-04-231-4/+2
| | | | | perl API functions called don't need a NUL terminated string. p4raw-id: //depot/perl@31038
* S_op_destroy() was not static. Also tidy all other STATIC/staticNicholas Clark2007-04-051-2/+1
| | | | | | declarations onto the same line as the return type, to make checking this easier. p4raw-id: //depot/perl@30846
* [perl #40427] Segfault in pack dgay@acm.org2006-10-031-0/+1
| | | | | | 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
* ; was RE: [PATCH perlio.c pp.c regcomp.c] silence format and comparison warningsRobin Barker2006-09-051-1/+1
| | | | | | From: "Robin Barker" <Robin.Barker@npl.co.uk> Message-ID: <2C2E01334A940D4792B3E115F95B7226120A21@exchsvr1.npl.ad.local> p4raw-id: //depot/perl@28786
* g++ large patchJarkko Hietaniemi2006-08-071-4/+4
| | | | | Message-ID: <44D2E203.5050201@iki.fi> p4raw-id: //depot/perl@28662
* Clear up most of the VC6 compiler warnings in the following smoke:Steve Hay2006-07-271-1/+1
| | | | | http://www.nntp.perl.org/group/perl.daily-build.reports/39733 p4raw-id: //depot/perl@28626
* clean some lint findingsAndy Lester2006-05-231-1/+1
| | | | | Message-ID: <20060521050240.GA21051@petdance.com> p4raw-id: //depot/perl@28289
* Re: [PATCH] upgrade bytes_to_uniSADAHIRO Tomoyuki2006-05-161-14/+6
| | | | | Message-Id: <20060515223901.F3B0.BQW10602@nifty.com> p4raw-id: //depot/perl@28209
* upgrade bytes_to_uniAndy Lester2006-05-121-11/+12
| | | | | Message-ID: <20060512052123.GA21648@petdance.com> p4raw-id: //depot/perl@28180
* Replace a STRLEN no_len; with a _nolen macro call.Nicholas Clark2006-04-301-2/+1
| | | p4raw-id: //depot/perl@28032
* Perl_pack_cat() is a mathom too!Nicholas Clark2006-04-301-22/+0
| | | p4raw-id: //depot/perl@28031
* One part of pp_pack couldn't correctly handle surprises from UTF-8Nicholas Clark2006-04-301-1/+12
| | | | | overloading. p4raw-id: //depot/perl@28030
* reduce gcc -ansi -pedantic noise plus a suggestionJarkko Hietaniemi2006-04-281-4/+4
| | | | | Message-ID: <44527402.8000506@gmail.com> p4raw-id: //depot/perl@28008
* Perl_unpack_str() is a mathom!Nicholas Clark2006-04-241-35/+0
| | | p4raw-id: //depot/perl@27956
* Re: [PATCH] s/Null(gv|hv|sv)/NULL/gSteven Schubiger2006-02-031-1/+1
| | | | | | Message-ID: <20060203152449.GI12591@accognoscere.homeunix.org> Date: Fri, 3 Feb 2006 16:24:49 +0100 p4raw-id: //depot/perl@27065
* Change all NEWSV() to newSV() in the core and non-dual-lived modules.Steve Hay2006-01-181-3/+3
| | | | | | | | 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
* sprinkle dVARJarkko Hietaniemi2006-01-061-1/+5
| | | | | Message-ID: <43BE7C4D.1010302@gmail.com> p4raw-id: //depot/perl@26675
* More copyright updatesRafael Garcia-Suarez2006-01-041-1/+1
| | | p4raw-id: //depot/perl@26652
* Introduce the macros newSVpvs(str) and sv_catpvs(sv, str).Gisle Aas2006-01-041-1/+1
| | | | | Gets rid of many hardcoded string lengths. p4raw-id: //depot/perl@26641
* op/pack.t failure on Win64Jan Dubois2005-12-311-0/+5
| | | | | Message-ID: <017a01c60d83$5dc73110$2217a8c0@candy> p4raw-id: //depot/perl@26549
* More consting, and putting stuff in embed.fncAndy Lester2005-12-061-3/+3
| | | | | Message-ID: <20051205194613.GB7791@petdance.com> p4raw-id: //depot/perl@26281
View Lorry Controller Status