summaryrefslogtreecommitdiff
path: root/pp_pack.c
Commit message (Collapse)AuthorAgeFilesLines
...
* pp_pack.c: Make pack('U', 0x41) eq 'A'Karl Williamson2014-11-241-4/+10
| | | | The 'U' pack/unpack format must be in terms of Unicode code points.
* pp_pack.c: Add commentKarl Williamson2014-11-241-1/+1
|
* Fix double FETCH with pack "w"Father Chrysostomos2014-09-271-2/+2
|
* pp_pack.c: Actually fix threaded buildsFather Chrysostomos2014-09-271-1/+1
|
* pp_pack.c: S_sv_check_inf =~ /$/nan/Father Chrysostomos2014-09-271-4/+4
| | | | At Jarkko Hietaniemi’s suggestion.
* Oops. Fix threaded builds.Father Chrysostomos2014-09-271-1/+1
|
* [perl #12285] Fix str vs num inf/nan treatmentFather Chrysostomos2014-09-271-40/+42
| | | | | | | sprintf, pack and chr were treating 0+"Inf" and "Inf" differently, even though they have the same string and numeric values. pack was also croaking for 0+"Inf" passed to a string format.
* infnan: in pack, first test for the unlikely infnan-ness.Jarkko Hietaniemi2014-09-251-7/+10
| | | | Also make the type I32, not char.
* infnan: perldiag entries fixing, add "in pack" to one message.Jarkko Hietaniemi2014-09-251-1/+1
|
* Make pack-as-int/sprintf-%c-ing/chr-ring inf/nan fatal.Jarkko Hietaniemi2014-09-231-24/+18
| | | | | | | | | | | | In pack: No point in trying to return all-bit-off/all-bits-one because inf/-inf/nan really don't map sensibly into integers. In printf-%c/chr: while U+FFFD would be an option, better to die on such weird input. pack-as-fp still works, sprintf-numeric still works. Make t/op/infnan.t to be less fragile about the number of expected tests.
* No point in pack 'w' for inf/nan.Jarkko Hietaniemi2014-09-221-1/+6
| | | | (For inf, the existing code already did this, slowly.)
* Missing "by" noticed by James Keenan.Jarkko Hietaniemi2014-09-211-1/+1
|
* Comments on unpack 'D' and long doubles formats.Jarkko Hietaniemi2014-09-211-0/+12
|
* pack c/C on inf/nan.Jarkko Hietaniemi2014-08-271-2/+17
| | | | | | | Made them return the 0xFF byte (and warn). Not necessarily the best choice, but there's not that much room in just 256 bytes for all of the inf/-inf/nan. This same choice will need to be made with wider integer packs.
* Remove or downgrade unnecessary dVAR.Jarkko Hietaniemi2014-06-251-6/+2
| | | | | | | | You need to configure with g++ *and* -Accflags=-DPERL_GLOBAL_STRUCT or -Accflags=-DPERL_GLOBAL_STRUCT_PRIVATE to see any difference. (g++ does not do the "post-annotation" form of "unused".) The version code has some of these issues, reported upstream.
* Revert "/* NOTREACHED */ belongs *before* the unreachable."Jarkko Hietaniemi2014-06-191-2/+1
| | | | | | This reverts commit 148f39b7de6eae9ddd59e0b0aff691d6abea7aca. (Still needs more work, but wanted to see how well this passed with Jenkins.)
* /* NOTREACHED */ belongs *before* the unreachable.Jarkko Hietaniemi2014-06-191-1/+2
| | | | | | Definitely not *after* it. It marks the start of the unreachable, not the first unrechable line. And if they are in that order, it looks better to linebreak after the lint hint.
* Some low-hanging -Wunreachable-code fruits.Jarkko Hietaniemi2014-06-151-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | - after return/croak/die/exit, return/break are pointless (break is not a terminator/separator, it's a goto) - after goto, another goto (!) is pointless - in some cases (usually function ends) introduce explicit NOT_REACHED to make the noreturn nature clearer (do not do this everywhere, though, since that would mean adding NOT_REACHED after every croak) - for the added NOT_REACHED also add /* NOTREACHED */ since NOT_REACHED is for gcc (and VC), while the comment is for linters - declaring variables in switch blocks is just too fragile: it kind of works for narrowing the scope (which is nice), but breaks the moment there are initializations for the variables (the initializations will be skipped since the flow will bypass the start of the block); in some easy cases simply hoist the declarations out of the block and move them earlier Note 1: Since after this patch the core is not yet -Wunreachable-code clean, not enabling that via cflags.SH, one needs to -Accflags=... it. Note 2: At least with the older gcc 4.4.7 there are far too many "unreachable code" warnings, which seem to go away with gcc 4.8, maybe better flow control analysis. Therefore, the warning should eventually be enabled only for modernish gccs (what about clang and Intel cc?)
* Revert "Some low-hanging -Wunreachable-code fruits."Jarkko Hietaniemi2014-06-131-7/+7
| | | | | | | This reverts commit 8c2b19724d117cecfa186d044abdbf766372c679. I don't understand - smoke-me came back happy with three separate reports... oh well, some other time.
* Some low-hanging -Wunreachable-code fruits.Jarkko Hietaniemi2014-06-131-7/+7
| | | | | | | | | | | | | | | | | | - after croak/die/exit (or return), break (or return!) are pointless (break is not a terminator/separator, it's a promise of a jump) - after goto, another goto (!) is pointless - in some cases (usually function ends) introduce explicit NOT_REACHED to make the noreturn nature clearer (do not do this everywhere, though, since that would mean adding NOT_REACHED after every croak) - for the added NOT_REACHED also add /* NOTREACHED */ since NOT_REACHED is for gcc (and VC), while the comment is for linters - declaring variables in switch blocks is just too fragile: it kind of works for narrowing the scope (which is nice), but breaks the moment there are initializations for the variables (they will be skipped!); in some easy cases simply hoist the declarations out of the block and move them earlier There are still a few places left.
* perlapi: Refactor placements, headings of some functionsKarl Williamson2014-06-051-0/+3
| | | | | | | | | | | | | | It is not very user friendly to list functions as "Functions found in file FOO". Better is to group them by purpose, as many were already. I went through and placed the ones that weren't already so grouped into groups. Patches welcome if you have a better classification. I changed the headings of some so that the important disctinction was the first word so that they are placed in the file more appropriately. And a couple of ones that I had created myself, I came up with a name that I think is better than the original
* Unify the "fall-through" lint annotation.Jarkko Hietaniemi2014-05-291-14/+14
| | | | | | | Used by linters (static checkers), and also good for human readers. Even though "FALL THROUGH" seems to be the most common, e.g BSD lint manual only knows "FALLTHROUGH" (or "FALLTHRU").
* Quad_t and Uquad_t cannot unpack as NVs.Jarkko Hietaniemi2014-05-291-6/+4
| | | | | | | | | | | If IVSIZE >= 8, a Quad_t is always >= IV_MIN, and <= IV_MAX, and an Uquad_t is always (>= 0 aka UV_MIN and) <= UV_MAX; they cannot escape their quadness and be NVs. (This logic may fail if Quad_t is not 8 bytes, but then other things would no doubt fail.) Also tighten the logic by adding HAS_QUAD, also for the pack case. Fix for Coverity perl5 CID 28942.
* perlapi: Consistent spaces after dotsFather Chrysostomos2013-12-291-1/+1
| | | | plus some typo fixes. I probably changed some things in perlintern, too.
* 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.
View Lorry Controller Status