summaryrefslogtreecommitdiff
path: root/pp_pack.c
Commit message (Collapse)AuthorAgeFilesLines
* fix wrong number of parameters for macro SHIFT_VARAlexandr Savca2018-10-111-2/+1
|
* (perl #132655) nul terminate result of unpack "u" of invalid dataTony Cook2018-09-211-1/+4
| | | | | In the given test case, Perl_atof2() would run off the end of the PV, producing an error from ASAN.
* (perl #131844) fix various space calculation issues in pp_pack.cTony Cook2018-04-161-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - for the originally reported case, if the start/cur pointer is in the top 75% of the address space the add (cur) + glen addition would overflow, resulting in the condition failing incorrectly. - the addition of the existing space used to the space needed could overflow, resulting in too small an allocation and a buffer overflow. - the scaling for UTF8 could overflow. - the multiply to calculate the space needed for many items could overflow. For the first case, do a space calculation without making new pointers. For the other cases, detect the overflow and croak if there's an overflow. Originally this used Size_t_MAX as the maximum size of a memory allocation, but for -DDEBUGGING builds realloc() throws a panic for allocations over half the address space in size, changing the error reported for the allocation. For non-DEBUGGING builds the Size_t_MAX limit has the small chance of finding a system that has 3GB of contiguous space available, and allocating that space, which could be a denial of servce in some cases. Unfortunately changing the limit to half the address space means that the exact case with the original issue can no longer occur, so the test is no longer testing against the address + length issue that caused the original problem, since the allocation is failing earlier. One option would be to change the test so the size request by pack is just under 2GB, but this has a higher (but still low) probability that the system has the address space available, and will actually try to allocate the memory, so let's not do that.
* Allow space for NUL is UTF-8 array declsKarl Williamson2018-01-221-2/+2
| | | | | | In grepping the source, I noticed that several arrays that are for holding UTF-8 characters did not allow space for a trailing NUL. This commit adds that.
* widen size-type variables in pack/unpackZefram2017-12-161-49/+49
| | | | | | Most size-type variables in pp_pack.c were of type I32, with a smattering of other types. Use SSize_t in place of I32, and generally use size_t-width variables as appropriate. Fixes [perl #119367].
* Change some strBEGINs() to memBEGINs()Karl Williamson2017-11-061-1/+1
| | | | | | The latter is generally faster when the length is already known. This commit also changes a few hard-coded numbers to use sizeof().
* Change some strncmp(), etc. to strBEGINs()Karl Williamson2017-11-061-1/+1
| | | | | The latter is much clearer as to what's going on, and the programmer and program reader don't have to count characters.
* pp_pack.c: simplify cpp conditionalsAaron Crane2017-10-211-13/+9
|
* pp_pack.c: Remove no longer relevant commentKarl Williamson2017-02-111-3/+0
|
* pp_pack.c: Remove needless branchKarl Williamson2017-02-111-7/+13
| | | | | | | This function only sets *retlen to 0 if the input length is 0. In all but one case, the function was not called with with that input. In that one case, I changed to avoid calling the function with that input. Hence we can remove checking *retlen for 0.
* pp_pack.c: Remove obsolete codeKarl Williamson2017-02-111-10/+5
| | | | | | | | | | This code effectively reduced to if (foo) 0 else 0 because a #define was changed to 0 some releases ago. Just replace by 0
* (perl #129149) avoid a heap buffer overflow with pack "W"...Tony Cook2017-01-171-1/+1
|
* Convert core (except toke.c) to use isFOO_utf8_safe()Karl Williamson2016-12-231-3/+8
| | | | | | | The previous commit added this feature; now this commit uses it in core. toke.c is deferred to the next commit to aid in possible future bisecting, because some of the changes there seem somewhat more likely to expose bugs.
* Change white space to avoid C++ deprecation warningKarl Williamson2016-11-181-4/+5
| | | | | | | | | | | | | | | | | | | | | | C++11 requires space between the end of a string literal and a macro, so that a feature can unambiguously be added to the language. Starting in g++ 6.2, the compiler emits a warning when there isn't a space (presumably so that future versions can support C++11). Unfortunately there are many such instances in the perl core. This commit fixes those, including those in ext/, but individual commits will be used for the other modules, those in dist/ and cpan/. This commit also inserts space at the end of a macro before a string literal, even though that is not deprecated, and removes useless "" literals following a macro (instead of inserting a blank). The result is easier to read, making the macro stand out, and be clearer as to the intention. Code and modules included with the Perl core need to be compilable using C++. This is so that perl can be embedded in C++ programs. (Actually, only the hdr files need to be so compilable, but it would be hard to test that just the hdrs are compilable.) So we need to accommodate changes to the C++ language.
* pp_pack.c: use new SvPVCLEAR and constant string friendly macrosYves Orton2016-10-191-1/+1
|
* Avoid emitting pack("p",...) warning erroneouslyFather Chrysostomos2016-07-291-1/+2
| | | | | A value may legitimately be marked SvTEMP even when it is not about to be freed.
* VAX: code changes for VAX floatsJarkko Hietaniemi2016-07-011-4/+6
| | | | | | | | | | | | | Mainly to avoid Inf and NaN, which VAX does does not have. There is something like Inf called "excess" but that is a deadly exception, seems to manifest itself in vax-netbsd either as a SIGFPE or SIGSEGV (pretty much untrappable at least from Perl level). The range of VAX floats is different from IEEE. There is positive zero, but no negative zero.
* make gimme consistently U8David Mitchell2016-02-031-1/+1
| | | | | | | | | | | | | The value of gimme stored in the context stack is U8. Make all other uses in the main core consistent with this. My primary motivation on this was that the new function cx_pushblock(), which I gave a 'U8 gimme' parameter, was generating warnings where callers were passing I32 gimme vars to it. Rather than play whack-a-mole, it seemed simpler to just uniformly use U8 everywhere. Porting/bench.pl shows a consistent reduction of about 2 instructions on the loop and sub benchmarks, so this change isn't harming performance.
* [perl #126325] don't read past the end of the source for pack [Hh]Tony Cook2015-11-111-1/+1
| | | | | With a utf8 target but a non-utf8 source, pack Hh would read past the end of the source when given a length, due to an incorrect condition.
* Various pods: Add C<> around many typed-as-is thingsKarl Williamson2015-09-031-8/+8
| | | | Removes 'the' in front of parameter names in some instances.
* [perl #125669] op/pack.t failures with PPC long double (double double) buildsSisyphus2015-08-201-1/+12
| | | | unpack '%65...' failures, to be more exact.
* pp_pack.c: Add commentKarl Williamson2015-08-011-1/+2
|
* packsizetables.c -> packsizetables.incJarkko Hietaniemi2015-07-221-1/+1
|
* pack('f', $NAN) must account for NAN_COMPARE_BROKEN platformsDaniel Dragan2015-05-201-0/+5
| | | | | | | VC6 was returning either packed float +inf or packed float -inf (I dont remember) instead of packed float NAN in t/op/infnan.t . This fixes #125203
* [perl #123971] fix long double pack padding on newer GCCTony Cook2015-04-101-0/+11
|
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | An empty cpan/.dir-locals.el stops Emacs using the core defaults for code imported from CPAN. Committer's work: To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed to be incremented in many files, including throughout dist/PathTools. perldelta entry for module updates. Add two Emacs control files to MANIFEST; re-sort MANIFEST. For: RT #124119.
* pp_pack.c: Silence compiler warningKarl Williamson2015-02-201-5/+5
| | | | | | | | | | | This was introduced by 9df874cdaa2f196cc11fbd7b82a85690c243eb9f in changing the name of some static functions. I didn't realize at the time that the function was defined in embed.fnc, as none of the others are, and it was always called with the S_ prefix form. Nor did I notice the compiler warnings. It turns out that the base name of this function is the same as a public function, so I've renamed it to have prefix 'S_my_'.
* [perl #123874] fix argument underflow for pack()Hugo van der Sanden2015-02-181-1/+1
| | | | | NEXTFROM() modified the item count while testing it, so the next use saw the count (of -1) as non-zero and ended up trying to write ~1 bytes.
* pp_pack.c: White-space onlyKarl Williamson2015-02-171-35/+35
| | | | | This outdents some code whose enclosing block was removed in the previous commit
* pp_pack.c: Rmv useless codeKarl Williamson2015-02-171-46/+6
| | | | | | | | As noted in the thread starting at http://nntp.perl.org/group/perl.perl5.porters/223366 and in the comments added in this commit, strings packed in 'u' format don't need any UTF-8ness special handling, so the code that did that can be removed.
* pp_pack.c: Refactor to remove #if EBCDICKarl Williamson2015-02-171-14/+7
| | | | | This commit causes the same code to be executed whether on an ASCII or EBCDIC platform.
* pp_pack.c: Change name of some static functionsKarl Williamson2015-02-171-24/+24
| | | | | Early code tends to conflate the terms Unicode and UTF-8. I find that confusing.
* pack(): avoid << of negative valuesDavid Mitchell2014-12-311-4/+4
| | | | | | | | | | Treat the string as U8* rather than char* when doing all the bit shifts for uuencode. That stops these warnings under ASan: pp_pack.c:1890:34: runtime error: left shift of negative value -127 pp_pack.c:1891:34: runtime error: left shift of negative value -126 pp_pack.c:1899:34: runtime error: left shift of negative value -1 pp_pack.c:1900:30: runtime error: left shift of negative value -31
* fix undefined float behaviour in pack('f')David Mitchell2014-12-311-1/+4
| | | | | | | | | | | | | | | | | | | | | The C standard says that the value of the expression (float)double_var is undefined if 'the value being converted is outside the range of values that can be represented'. So to shut up -fsanitize=undefined: my $p = pack 'f', 1.36514538e67; giving runtime error: value 1.36515e+67 is outside the range of representable values of type 'float' explicitly handle the out of range values. Something similar is already done under defined(VMS) && !defined(_IEEE_FP), except that there it floors to +/- FLT_MAX rather than +/- (float)NV_INF. I don't know which branch is best, and whether they should be merged. This fix was suggested by Aaron Crane.
* Don’t do string overloading for numeric pack fmtsFather Chrysostomos2014-12-101-3/+8
| | | | See <20141130160250.GC31019@pjcj.net>. Commit 354b74ae6f broke this.
* 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.
View Lorry Controller Status