summaryrefslogtreecommitdiff
path: root/ext/XS-APItest
Commit message (Collapse)AuthorAgeFilesLines
* regexec.c - fix memory leak in EVAL.Yves Orton2023-01-152-0/+46
| | | | | | | | | | | | | | | | | | EVAL was calling regcppush twice per invocation, once before executing the callback, and once after. But not regcppop'ing twice. So each time we would accumulate an extra "frame" of data. This is/was hidden somewhat by the way we eventually "blow" the stack, so the extra data was just thrown away at the end. This removes the second set of pushes so that the save stack stays a stable size as it unwinds from each failed eval. We also weren't cleaning up after a (?{...}) when we failed to match to its right. This unwinds the stack and restores the parens properly. This adds tests to check how the save stack grows during patterns using (?{ ... }) and (??{ ... }) and ensure that when we backtrack and re-execute the EVAL again it cleans up the stack as it goes.
* av.c - av_store() do the refcount dance around magic av'sYves Orton2023-01-092-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The api for av_store() says it is the callers responsibility to call SvREFCNT_inc() on the stored item after the store is successful. However inside of av_store() we store the item in the C level array before we trigger magic. To a certain extent this is required because mg_set(av) needs to be able to see the newly stored item. But if the mg_set() or other magic associated with the av_store() operation fails, we would end up with a double free situation, as we will long jump up the stack above and out of the call to av_store(), freeing the mortal as we go (via Perl_croak()), but leaving the reference to the now freed pointer in the array. When the next SV is allocated the reference will be reused, and then we are in a double free scenario. I see comments in pp_aassign talking about defusing the temps stack for the parameters it is passing in, and things like this, which at first looked related. But that commentary doesn't seem that relevant to me, as this bug could happen any time a scalar owned by one data structure was copied into an array with set magic which could die. Eg, I can easily imagine XS code that expected code like this (assume it handles magic properly) to work: SV **svp = av_fetch(av1,0,1); if (av_store(av2,0,*svp)) SvREFCNT_inc(*svp); but if av2 has set magic and it dies the end result will be that both av1 and av2 contain a visible reference to *svp, but its refcount will be 1. So I think this is a bug regardless of what pp_aassign does. This fixes https://github.com/Perl/perl5/issues/20675
* XS-APItest/t/locale.t - deal with indented values properlyYves Orton2022-12-301-1/+1
| | | | | | | | | The old code used a regex that would split on exactly one space, so if the data was changed to have more than one then it would get absorbed into the name that was parsed out of the header file, leading the code to test for things like "FOO ", which of course don't exist. Likely this could have caused other issues too, but the defines in practice are single symbols.
* sv.c - add support for HvNAMEf and HvNAMEf_QUOTEDPREFIX formatsYves Orton2022-12-223-2/+33
| | | | | | | | They are similar to SVf and SVf_QUOTEDPREFIX but take an HV * argument and use HvNAME() and related macros to extract the string. This is helpful as it makes constructing error messages from a stash (HV *) easier. It is the callers responsibility to ensure that the HV is actually a stash.
* gv.c - rename amagic_find() to amagic_applies()Yves Orton2022-12-223-1/+74
| | | | | | | | | The api for amagic_find() didnt make as much as sense as we thought at first. Most people will be using this as a predicate, and don't care about the returned CV, so to simplify things until we can really think this through the required API this switches it to return a bool and renames it to amagic_applies(), as in "which amagic_applies to this sv".
* Fix broken API: sync_locale()Karl Williamson2022-12-201-6/+2
| | | | | | | | | | | | | | This fixes GH #20565. Lack of tests allowed sync_locale() to get broken until CPAN testing showed it so. Basically, I blew it in 9f5a615be674d7663d3b4719849baa1ba3027f5b. Most egregiously, I forgot to turn back on when a sync_locale() is executed, the toggling for locales whose radix character isn't a dot. And this needs a way to tell the other code that it needs to recompute things at this time, since our records don't reflect what happened before the sync.
* Add testing global locale switching; Todo #20565Karl Williamson2022-12-202-0/+60
| | | | | | API switch_to_global_locale() and sync_locale() weren't tested because I hadn't figured out a way to do so, but @dk showed me the way in his reproducing case for GH #20565.
* API-test:locale.t: Look for a comma radix localeKarl Williamson2022-12-201-5/+7
| | | | | | | | | | | Prior to this commit there was code (whose results were ignored) looking for a locale with a non-dot radix. This can result in a UTF-8 radix, which may not display properly without the terminal and file handle being in sync. Almost all non-dot locales use a comma, which is represented the same in UTF-8 as not, so doesn't suffer from the display problem. So look specifically for a comma. The result is still unused, but the next commit will use it.
* utf8_hop forwards Change continuation start behaviorKarl Williamson2022-12-071-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this commit, when hopping forwards, and the initial position to hop from is a continuation byte, it treats it and each such successive one as a single character until it gets to a start byte, and switches into normal mode. In contrast, in hopping backwards, all the consecutive continuation bytes are considered to be part of a single character (as they indeed are). Thus there is a discrepancy between forward/backwards hopping; and the forward version seems wrong to me. This commit removes the discrepancy. There is no change in behavior if the starting position is to the beginning of a character. All calls in the core except for the API test are of this form. But, if the initial position is in the middle of a character, it now moves to the beginning of the next character, subtracting just 1 from the count of characters to hop (instead of subtracting however many continuation bytes there are). This is how I would have expected it to work all along. Succinctly, getting to the next character now consumes one hop count, no matter the direction nor which byte in the character is the starting position.
* APItest: Generalize hop test for EBCDICKarl Williamson2022-12-071-3/+2
| | | | And stop skipping it
* ext/XS-APItest/APItest.pm: Bump $VERSIONJames E Keenan2022-11-211-1/+1
| | | | Oversight in b17e77fbd8
* test SvPVbyte*() and SvPVutf8*() variants set lenTony Cook2022-11-213-19/+48
| | | | | | | | | | | These macros have limited use in core: - only Socket uses SvPVbyte_nomg() - nothing uses SvPVutf8_nomg() Update the existing tests to ensure len is set properly. Related to #20507
* only fully calculate the stash (effective) name where neededTony Cook2022-11-181-1/+1
| | | | | | | | | gcc 12 was complaining that evaluating (somehekptr)->hek_key was always true in many places where HvNAME() or HvENAME() was being called in boolean context. Add new macros to check whether the names should be available and use those instead.
* Add tests for value magicLeon Timmermans2022-11-012-4/+19
|
* Test localization of ext magicLeon Timmermans2022-11-011-1/+8
|
* Simplify magic testLeon Timmermans2022-11-013-6/+6
|
* ext/lib - bump module versions on Opcode.pm, APItest and DeparseYves Orton2022-09-081-1/+1
|
* Add PUSHpvs("literal") macro familyPaul "LeoNerd" Evans2022-08-241-2/+2
| | | | | | | | | | | | | | This set of PUSH-style macros takes a string literal argument and pushes it to the stack, optionally mortalizing it and/or extending the stack. Previously, the best alternative was mPUSHp("literal", 7); which required the author to visually count the number of characters in the string literal (7 in this case). These new macros fit the similar pattern familiar to many functions such as `newSVpvs`, which takes a string literal and counts it directly.
* Define a CvREFCOUNTED_ANYSV flagPaul "LeoNerd" Evans2022-08-163-1/+44
| | | | | | | | If this flag is set, then the CvXSUBANY(cv).any_sv pointer will have its reference count decremented when the CV itself is freed. This is useful for XS extensions that wish to store extra data in here. Without this flag, such extensions have to resort to using magic with a 'free' function to perform this work.
* APItest:locale.t: Use proper test for LC_ALL presenceKarl Williamson2022-07-261-1/+1
| | | | | If no LC_ALL, there won't be an LC_ALL() sub. Instead use the string 'LC_ALL" and an explicit check to see if it is there.
* fixup XS::APItest::gimme() return valueDavid Mitchell2022-07-201-1/+4
| | | | | | | | Make this recently-added test function always return something, so that assigning its return value to a scalar variable doesn't underflow the stack. (I spotted this while debugging something else.)
* Add `newAVav()` and `newAVhv()`Paul "LeoNerd" Evans2022-07-132-0/+63
|
* Finish changing offset to hopKarl Williamson2022-07-101-2/+2
| | | | | This is a follow on to 0e647b0520a120213d2074ede2609a10076f2f8d, to finish changing the variable names to not be as confusing.
* APItest: Change comments/variable namesKarl Williamson2022-07-102-5/+4
| | | | | | These for hopping within a string had two items whose name both contained 'offset', confusing things. One of them is the number of characters to hop. Rename for clarity.
* goto(&xs_sub): provide correct caller contextDavid Mitchell2022-07-062-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GH #19188 in something like sub foo { goto &xs_sub } if the XS subroutine tries to get its caller context using GIMME_V, it used to always be reported as scalar, since the OP_GOTO is the current op being executed, and that op is marked as scalar. The correct answer should be to return the context of the caller of foo(), but that information is lost as, just before calling the XS sub, pp_goto pops the CXt_SUB off the context stack which holds the recorded value of the context of the caller. The fix in principle is for goto, just before calling the XS sub, to grab the gimme value from the about-to-be-popped CXt_SUB frame, and set OP_GOTO op's op_flag field with that gimme value. However, modifying ops at runtime isn't allowed, as ops are shared between threads. So instead set up a fake copy of the OP_GOTO and alter the gimme value in that instead. I'm pretty confident that on an exception, a LEAVE_SCOPE() will always be done before the JMPENV_JUMP(), so PL_op will be restored to its original value *before* the CPU stack is restored to it's old value (leaving the temporary OP_GOTO as garbage in an abandoned stack frame).
* Change !! to cBOOL() in dist/ext modulesKarl Williamson2022-06-201-1/+1
|
* Revert "Do per-word hop back"Karl Williamson2022-06-141-3/+0
| | | | | | | This reverts commit d6ad3b72778369a84a215b498d8d60d5b03aa1af and adds comments that it existed. This is so that this work which isn't really needed based on current usage in core isn't lost, and can be used in the future.
* Do per-word hop backKarl Williamson2022-06-141-0/+3
| | | | | | | This should speed up backing up a large distance in a UTF-8 string. But we don't actually do that in core. I did this work 5 years ago before I realized this. Rather than throw it away, this commit gets it into the history, and the next commit will revert it.
* APItest.xs: flush output in test_bool_internals_funcLeon Timmermans2022-05-301-0/+1
| | | | | | With the explicit flush this test will fail when PERLIO=stdio, because stdio defaults to block-based buffering on pipes and therefore the output will come out wrong.
* XS-APItest - add tests for new API calls and for bool internalsYves Orton2022-05-274-2/+107
| | | | | | We do not have any tests for the bool internals. This creates a bunch of them to test and validate the various new API calls for creating and setting bools.
* APItest/t/sv_streq.t: Generalize for EBCDICKarl Williamson2022-03-261-7/+7
| | | | | | | | This test fails on EBCDIC systems, because it wants a non-ASCII character, and the one it chose, E9, is ASCII on EBCDIC ('Z'). perlhacktips suggests B6 as a character to use in such tests, and this commit changes to use that.
* Add test for the previous commit fixing Perl_my_strtodTAKAI Kousuke2022-03-052-0/+31
| | | | Perl core itself seems not to call my_strtod, so test it with XS::APItest.
* gh19010: simplify and expand inf/nan testsHugo van der Sanden2022-03-041-30/+36
| | | | | | We know how grok results should vary with and without PERL_SCAN_TRAILING both for inputs with trailing garbage and those without, so abstract that out and test both cases for each input.
* gh19010: fix returns for Perl_grok_infnanHugo van der Sanden2022-03-041-7/+10
| | | | | | | | | | | | | | | Consistently honour what the docs have always promised: If an infinity or a not-a-number is recognized, C<*sp> will point to one byte past the end of the recognized string. If the recognition fails, zero is returned, and C<*sp> will not move. Additionally, restore Perl_grok_number_flags to allowing inf/nan with trailing garbage only when called with PERL_SCAN_TRAILING; add notes to the other two core callers to clarify that they always accept such trailing garbage. A small number of XS-APItest tests were modified to reflect the stricter behaviour: "Infin" and "nanx" are now invalid without PERL_SCAN_TRAILING.
* Fix UTF8_IS_REPLACEMENT() and add testsKarl Williamson2022-03-013-1/+17
| | | | | | | This macro relied on a now-removed other macro in 2019, 216dc346ceeeb9b6ba0fdd470ccfe4f8b2a286c4. Fix it and add tests. This bug was caught by Devel::PPPort
* Also document and unit-test the correct handling of UTF-8Paul "LeoNerd" Evans2022-01-271-2/+16
|
* Slight tidying of testsPaul "LeoNerd" Evans2022-01-272-6/+8
|
* Create sv_streq() API family, as a stringy copy of the sv_numeq() onesPaul "LeoNerd" Evans2022-01-272-0/+43
|
* Have sv_numeq() respect == overloading unless the SV_SKIP_OVERLOAD flag is ↵Paul "LeoNerd" Evans2022-01-262-2/+16
| | | | passed
* Initial implementation of sv_numeq() and _flags() variantPaul "LeoNerd" Evans2022-01-264-1/+33
|
* Fix unit tests for experimental::builtin warningsPaul "LeoNerd" Evans2022-01-252-0/+2
|
* Change pack U behavior for EBCDICKarl Williamson2021-12-281-2/+0
| | | | | | | | | | This effectively reverts 3ece276e6c0. It turns out this was a bad idea to make U mean the non-native official Unicode code points. It may seem to make sense to do so, but broke multiple CPAN modules which were using U the previous way. This commit has no effect on ASCII-platform functioning.
* use is_deeply instead of eq_ Test::More functionsMichiel Beijen2021-12-241-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the eq_set, eq_hash, and eq_array functions in Test::More are discouraged to use, and is_deeply is recommended. Ref: https://metacpan.org/pod/Test::More#Discouraged-comparison-functions The reason for this is that, if the tests fail, is_deeply has much better diagnostics. The other thing is that is_deeply is a test function directly, where eq_hash and such need to be wrapped inside ok(). This is easy to forget -- proof of this is in Benchmark.t, where we had this code, that did not test anything: eq_set([keys %$got], [qw(Foo Bar Baz)], 'should be exactly three objects'); It is now replaced by: is_deeply([sort keys %$got], [sort qw(Foo Bar Baz)], 'should be exactly three objects'); this commit replaces all usage of eq_set, eq_hash, and eq_array in lib/ and ext/ for tests that use Test::More. One small exception is where a negated test is used; Test::More does not have is_not_deeply() or such. Test2 has `isnt()` for this, but that is not in core. In those cases, we still keep using the eq_ operators.
* Use builtin::reftype/refaddr in .t filesPaul "LeoNerd" Evans2021-12-081-1/+1
|
* Use builtin::weaken() in .t files in lib/ + ext/Paul "LeoNerd" Evans2021-12-082-2/+1
|
* Fix the build and tests when NODEFAULT_SHAREKEYS is definedNicholas Clark2021-10-201-0/+4
| | | | | Defining this macro causes newHV() to create hashes without shared hash key scalars. The default is that hashes are created with shared hash keys.
* Rename HE_SVSLOT to HE_ARENA_ROOT_IXNicholas Clark2021-10-112-4/+4
| | | | | | The longer name more accurately reflects what the constant refers to. Correct the comments describing how some arena roots are re-used.
* Avoid a use-after-free deleting 8-bit keys from stashesNicholas Clark2021-09-161-0/+19
| | | | | | | | | | | | | This code path only affects symbol tables, and can't be reached by regular Perl code. It is only reachable using the XS API to delete a key from a stash where the key was in the 8-bit range but passed in UTF-8 encoded. This has been in the code since it was added in Oct 2010 by commit 35759254f69c7bfa: Rename stashes when they move around Also there is no need to call SvPV() on keysv in S_hv_delete_common() as its caller has always already done this. This entire code is not KISS.
* Test SvIsBOOL() using XS::APItestPaul "LeoNerd" Evans2021-09-153-0/+91
| | | | | Copy the Scalar::Util::isbool() tests into XS-APItest so we can avoid relying on Scalar::Util just to check core functionality
* APItest.xs: remove unneeded SvPV_force_nolen()David Mitchell2021-09-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | The two API test wrappers utf16_to_utf8_reversed() and utf8_to_utf16(_reversed() included a call to SvPV_force_nolen(), because the underlying functions in utf8.c which they were wrapping used to modify the src buffer. However since v5.35.2-236-g5fd26678bf, these functions no longer modify the buffer, so the force is superfluous. So this commit removes force. As a side-effect, this fixes a failure in cd t; ./TEST -deparse ../ext/XS-APItest/t/utf16_to_utf8.t because the test file has this line: $utf16_of_U10302 = utf8_to_utf16_reversed(chr 0x10302); which after a round trip through deparse becomes: $utf16_of_U10302 = utf8_to_utf16_reversed("\x{10302}"); and it so happens that at compile time, the chr() form gets constant- folded into a modifiable PADTMP string constant, which survives a call to SvPV_force(), while the latter form is a pure read-only constant SV which croaks with "Modification of a read-only value attempted"
View Lorry Controller Status