summaryrefslogtreecommitdiff
path: root/pp_pack.c
Commit message (Collapse)AuthorAgeFilesLines
* Use IVSIZE not HAS_QUAD to enable 'q' and 'Q' formats in pack.Nicholas Clark2013-09-171-4/+4
| | | | | | | | | | | Whilst the code for 'q' and 'Q' in pp_pack is itself well behaved if enabled on a perl with 32 bit IVs (using SvNV instead of SvIV and SvUV), the regression tests are not. Several tests use an eval of "pack 'q'" to determine if 64 bit integer support is available (instead of $Config{ivsize}), and t/op/pack.t fails many tests. While these could be fixed (or skipped), unfortunately the approach of evaling "pack 'q'" is fairly popular on CPAN, so the breakage isn't just in the perl core, and might also be present in code we can't see or submit patches for.
* Use separate macros for byte vs uv UnicodeKarl Williamson2013-09-101-1/+1
| | | | | | | This removes a macro not yet even in a development release, and splits its calls into two classes: those where the input is a byte; and those where it can be any unsigned integer. The byte implementation avoids a function call on EBCDIC platforms.
* Convert some uvuni() to uvchr()Karl Williamson2013-08-291-7/+7
| | | | | All the tables are now based on the native character set, so using uvuni() in almost all cases is wrong.
* Extract common code to an inline functionKarl Williamson2013-08-291-14/+2
| | | | | This fairly short paradigm is repeated in several places; a later commit will improve it.
* Annotate the "cold" paths in pp_pack.c with UNLIKELY().Nicholas Clark2013-05-201-7/+7
| | | | The usual case is nice regular bytes in the host's nice regular order.
* When endian-swapping in pack, simply copy the bytes in reverse order.Nicholas Clark2013-05-201-72/+64
| | | | | This should restore support for big endian Crays. It doesn't support mixed-endian systems.
* Pass 'needs_swap' as a parameter to SHIFT_BYTES.Nicholas Clark2013-05-201-29/+32
| | | | | | | It feels wrong to have it as an implicit parameter sucked in via the textual expansion of the macro. Whilst it can be derived from the parameter 'datumtype', it seems that the C compiler generates a lot less efficient code that way.
* When endian-swapping in unpack, simply copy the bytes in reverse order.Nicholas Clark2013-05-201-6/+26
| | | | | | | | | | | It is considerably simpler to re-order the bytes before reading them into the variable of the desired type, than to read into the variable and then need a specialised "reverse this integer" function for each size of integer. This should restore support for big endian Crays. It doesn't support mixed-endian systems. Support for mixed-endian systems can be restored (if needed) by re-ordering the bytes correctly at the locations which currently only know how to reverse the bytes.
* Fold the implementation of DO_BO_UNPACK into SHIFT_BYTES(), its only user.Nicholas Clark2013-05-201-29/+3
|
* Re-implement SHIFT16 and SHIFT32 as wrappers to SHIFT_BYTES.Nicholas Clark2013-05-201-20/+6
|
* Refactor the two uses of SHIFT{16,32} not followed by DO_BO_UNPACK().Nicholas Clark2013-05-201-0/+6
| | | | | | | | | | | There is one place where SHIFT16() is not immediately followed by DO_BO_UNPACK() ('n!' and 'v!'), and one place where SHIFT32() is not immediately followed by DO_BO_UNPACK() ('N!' and 'V!'). Every other use of either macro is followed by DO_BO_UNPACK(). For the two locations that don't have DO_BO_UNPACK(), the modifiers '<' and '>' are illegal, hence DO_BO_UNPACK() will always be a no-op. Hence add DO_BO_UNPACK() to both (which permits refactoring to simplify things), and add assert()s that the assumptions are true.
* Remove the now unused 'type' argument from the macros DO_BO_(UN)?PACK.Nicholas Clark2013-05-201-41/+41
|
* As DO_BO_(UN)?PACK are now implemented with my_swabn(), simplify 'J' and 'j'.Nicholas Clark2013-05-201-36/+4
| | | | | | The conditionally compiled code to figure out the correct named integer size for UVs and IVs is no longer needed, as my_swabn() will swap UVs and IVs, whatever their length.
* Merge the identical definitions of DO_BO_UNPACK and DO_BO_PACK.Nicholas Clark2013-05-201-39/+0
| | | | | | Delete the now-unused mixed-endian definitions of DO_BO_UNPACK and DO_BO_PACK, and the macro BO_CANT_DOIT, as they were the last two things using it.
* Swap byte order in DO_BO_(UN)?PACK based on a variable needs_swap.Nicholas Clark2013-05-201-4/+19
| | | | | | | | | | Add the macro NEEDS_SWAP to initialise needs_swap based on TYPE_ENDIANNESS(datumtype). This makes the two definitions of DO_BO_UNPACK identical, and the two definitions of DO_BO_PACK identical. This also makes building pp_pack.c on a mixed endian byteorder architecture a compile time error. The commit adds pointers on where to add code to re-instate support for such architectures.
* DO_BO_{UN,}PACK can use my_swabn() directly.Nicholas Clark2013-05-201-4/+4
| | | | | This removes the only users of my_{be,le,h}to{be,le,h}n, so remove the definitions for those macros.
* Use DO_BO_{UN,}PACK in place of DO_BO_UNPACK_{N,PC}Nicholas Clark2013-05-201-92/+11
| | | | Also, eliminate the intermediate macros DO_BO_PACK_PTR and DO_BO_UNPACK_PTR.
* In pp_pack.c, refactor DO_BO_(UN)?PACK to use my_letohn etcNicholas Clark2013-05-201-4/+4
| | | | | | | | | | Previously they were using a my_letoh* function for the appropriate size. This commit probably breaks fixed 16 and 32 bit templates on big endian Crays where sizeof(short) and sizeof(int) are 8. A future commit will restore support. (Although it's not clear whether such Crays can still build blead cleanly, as we've not had any feedback since Boeing decommissioned their Cray.)
* In pp_pack.c, refactor DO_BO_(UN)?PACK_PTR to use my_letohn etcNicholas Clark2013-05-201-4/+4
| | | | | | Previously they were casting the pointer to an integer value, calling a my_letoh* function for the appropriate size, and casting the return value back to a pointer.
* In pp_pack.c, refactor DO_BO_(UN)?PACK_N to use sizeof() on the variable.Nicholas Clark2013-05-201-4/+4
| | | | | | Previously they were using sizeof() on the type argument passed to the macro. This change makes their implementation more like DO_BO_(UN)?PACK and DO_BO_(UN)?PACK_PTR.
* Refactor macros in pp_pack.c, removing support for mixed-endian byte orders.Nicholas Clark2013-05-201-48/+77
| | | | | | | | | | The byte-order handling can be simplified considerably if we don't have to support mixed-endian systems. It's not clear whether Perl 5.000 even compiled on PDP-11s, let alone more recent versions. Support probably can be added back at the end of the refactoring, if someone has time and a PDP-11 to test on, but for the intermediate stages it is a lot easier not to need to think about such platforms.
* Provide ntohl, ntohs, htonl and htons no-op macros on big endian systems.Nicholas Clark2013-05-201-12/+0
| | | | | | | | | | | This means that there are always macros or functions for ntohl, ntohs, htonl and htons available, so eliminate use of HAS_NTOHL etc, and unconditionally compile the code that it was protecting. However, as code on CPAN is using these guard macros, define all of them in perl.h (Technically the 4 are not quite no-ops, as they truncate their values to 32 or 16 bits, to be consistent with the implementations for platforms which need re-ordering.)
* Provide vtohl, vtohs, htovl and htovs no-op macros on little endian systems.Nicholas Clark2013-05-201-12/+0
| | | | | | | | | | | This means that there are always macros or functions for vtohl, vtohs, htovl and htovs available, so eliminate HAS_VTOHL etc, and unconditionally compile the code that it was protecting. grep.cpan.me shows that no code on CPAN uses any of these macros. (Technically the 4 are not quite no-ops, as they truncate their values to 32 or 16 bits, to be consistent with the implementations for platforms which need re-ordering.)
* Eliminate the definitions for DO_BO_PACK_P and DO_BO_UNPACK_P.Nicholas Clark2013-05-201-10/+0
| | | | | Commit 07409e015252427f in April 2005 replaced all the uses of these two macros with DO_BO_PACK_PC and DO_BO_UNPACK_PC.
* Eliminate pre-5.9.x conditional code for PERL_PACK_CAN_SHRIEKSIGNNicholas Clark2013-05-201-51/+7
| | | | | | | PERL_PACK_CAN_SHRIEKSIGN has been unconditionally defined for versions 5.9.x and greater, and undefined for 5.8.x. As we are never going to need to port changes back to maint-5.8 any more, eliminate all the 5.8.x related code and the macro that supports it.
* Eliminate pre-5.9.x conditional code for PERL_PACK_CAN_BYTEORDERNicholas Clark2013-05-201-25/+0
| | | | | | | PERL_PACK_CAN_BYTEORDER has been unconditionally defined for versions 5.9.x and greater, and undefined for 5.8.x. As we are never going to need to port changes back to maint-5.8 any more, eliminate all the 5.8.x related code, and the macro that supports it.
* Extract the generated packprops array into packsizetables.c.Nicholas Clark2013-05-201-249/+1
| | | | | | | The C source is the output from genpacksizetables.pl Previously it was pasted into pp_pack.c LocalWords: packprops
* improve unpackstring() API docsDavid Mitchell2013-05-061-5/+15
| | | | See ticket RT #116366 for the full discussion
* Remove VOS floating-point workaround; VOS bug long since fixedPaul Green2013-03-191-34/+0
|
* better POD for unpackstringDaniel Dragan2013-01-131-1/+3
| | | | | Someone asked me how to use unpackstring() since they couldn't figure it out from the docs, so I added some things.
* Proper IEEE overflow semantics for VMS.Craig A. Berry2012-12-231-2/+2
| | | | | | | | | | | Way back in 67597c89125e7e14 we misspelled _IEEE_FP as __IEEE_FP, with a spurious leading underscore. Which I then copied and pasted into pp_pack.c in baf3cf9c09c529. This means that on Alpha and Itanium systems with the default selection of IEEE floating point, we've actually (for the last decade!) been using a workaround intended for VAX or Alpha and Itanium builds that have explicitly selected VAX-compatible floating point formats. Oh well.
* pp.c pp_pack.c: Use macro instead of functionKarl Williamson2012-12-091-1/+1
| | | | | | | This converts to use is_SPACE_utf8() instead of the (soon to be deprecated) is_utf8_space(). The macro is faster, avoiding the function call completely, so the performance need to make a special case for a SPACE character is gone.
* Remove "register" declarationsKarl Williamson2012-11-241-3/+3
| | | | | | | 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
* pp_pack.c: Simplify sv length determination in one spotFather Chrysostomos2012-10-011-12/+1
| | | | | | | sv_len_utf8 is now careful not to record caches on magical or over- loaded scalars (any non-PV, in fact). It also returns the number of logical characters correctly, regardless of whether its input is utf8. So we can greatly simplify this code.
* Stop calling get-magic twice in pack "u", $utf8Father Chrysostomos2012-08-301-1/+1
|
* 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
|
View Lorry Controller Status