summaryrefslogtreecommitdiff
path: root/av.c
Commit message (Collapse)AuthorAgeFilesLines
* Add reference to av_extend_guts zeroing discussionHugo van der Sanden2021-04-061-1/+2
| | | | .. via withdrawn PR 18690.
* av_extend_guts: set correct ary_offset when unshifting an array (GH#18667)Richard Leach2021-04-051-0/+1
|
* style: Detabify indentation of the C code maintained by the core.Michael G. Schwern2021-01-171-247/+247
| | | | | | | | | | | This just detabifies to get rid of the mixed tab/space indentation. Applying consistent indentation and dealing with other tabs are another issue. Done with `expand -i`. * vutil.* left alone, it's part of version. * Left regen managed files alone for now.
* Fix documentation grammarTom Hukins2020-11-201-1/+1
| | | | | Replace "Frees the all the" with "Frees all the". The original wording was introduced in c2217cd33590ef654 and a4395ebabc8655115.
* autodoc.pl: Specify scn for single-purpose filesKarl Williamson2020-11-061-4/+0
| | | | | | | | Many of the files in perl are for one thing only, and hence their embedded documentation will be for that one thing. By creating a hash here of them, those files don't have to worry about what section that documentation goes under, and so it can be completely changed without affecting them.
* av_make: remove unnecessary AvFILLp assignmentRichard Leach2020-11-041-2/+1
| | | | | | | av_make sets `AvFILLp(av)= -1;`, but will already have been set by `newAV()`, via `newSV_type`'s call to `sv_upgrade`. This PR also includes the minor cosmetic change of swapping in `newAV()` in place of its expansion, seemingly the only occurrence of that in core.
* Perl_av_extend_guts: use Zero() rather than a while loop to set NULLsRichard Leach2020-10-041-35/+42
|
* Perl_av_extend_guts: tabs converted to spaces; unnecessary nesting removedRichard Leach2020-10-041-89/+85
|
* Remove Perl_av_top_indexKarl Williamson2020-09-291-10/+0
| | | | | | | | | I created this in 87306e0674dfe3af29804b4641347cd5ac9b0521, thinking it was needed to preserve backward compatibility if someone were using this instead of the macro. But it turned out that there never was such a function, it was inlined, and the name was S_av_top_index, so there is no reason to create a new function that no one has ever been able to call. So just remove it, and let all accesses go through the macro
* Document AvFILLp; clarify related entriesKarl Williamson2020-09-131-6/+11
|
* Reorganize perlapiKarl Williamson2020-09-041-1/+1
| | | | | This uses a new organization of sections that I came up with. I asked for comments on p5p, but there were none.
* Add av_count()Karl Williamson2020-08-191-3/+14
| | | | | | | | | This returns the number of elements in an array in a clearly named function. av_top_index(), av_tindex() are clearly named, but are less than ideal, and came about because no one back then thought of this one, until now Paul Evans did.
* pp_sort.c: fix fencepost error in call to av_extend()Yves Orton2020-01-311-2/+16
| | | | | | | | | | | | | | | | | | | In [rt.cpan.org #39196] issue #17496 there is a report that Tie::File produced spurious blank lines in the file after @tied= sort @tied; it turns out that this is because Tie::File treats EXTEND similarly to STORESIZE (which is arguably not entirely correct, but also not that weird) coupled with an off by one error in the calls to av_extend() in pp_sort. This patch fixes the fencepost error, adds some comments to av_extend() to make it clear what it is doing, and adds a test that EXTEND is called by this code with correct argument.
* Revert "Add some defensive coding to av_store()"Karl Williamson2020-01-021-2/+2
| | | | | | | | | | | | | | | | This reverts commit bc62bf8519f9005df2fb29dbd3d330202b258b6b. As Dave Mitchell said in <Perl/perl5/issues/17265/570253376@github.com> "The docs for av_store() say that the caller is responsible for first incrementing the ref count of the new SV before passing it to av_store(). In the normal case of the two elements being different, av_store() will decrement the old SV before storing the new one, and everything is good. When the two elements are the same SV, av_store() *still* needs to decrement the ref count, to undo the increment the caller just did." This should resolve GH #17265
* Add some defensive coding to av_store()Karl Williamson2019-06-271-2/+2
| | | | | | | | | | | Don't decrement the reference count of the element about to be stored into. Likely, this is an error in the caller, but doing this action blindly is like shooting yourself in the foot. The branch prediction also added ensures this shouldn't slow things down. See http://nntp.perl.org/group/perl.perl5.porters/254974
* rmv/de-dup static const char array "strings"Daniel Dragan2018-03-071-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MSVC due to a bug doesn't merge identicals between .o'es or discard these vars and their contents. MEM_WRAP_CHECK_2 has never been used outside of core according to cpan grep MEM_WRAP_CHECK_2 was removed on the "have PERL_MALLOC_WRAP" branch in commit fabdb6c0879 "pre-likely cleanup" without explination, probably bc it was unused. But MEM_WRAP_CHECK_2 was still left on the "no PERL_MALLOC_WRAP" branch, so remove it from the "no" side for tidyness since it was a mistake to leave it there if it was removed from the "yes" side of the #ifdef. Add MEM_WRAP_CHECK_s API, letter "s" means argument is string or static. This lets us get rid of the "%s" argument passed to Perl_croak_nocontext at a couple call sites since we fully control the next and only argument and its guaranteed to be a string literal. This allows merging of 2 "Out of memory during array extend" c strings by linker now. Also change the 2 op.h messages into macros which become string literals at their call sites instead of "read char * from a global char **" which was going on before. VC 2003 32b perl527.dll section size before .text name DE503 virtual size .rdata name 4B621 virtual size after .text name DE503 virtual size .rdata name 4B5D1 virtual size
* ‘Nonelems’ for pushing sparse array on the stackFather Chrysostomos2018-02-181-0/+13
| | | | | | | | | | | | | | | | | To avoid having to create deferred elements every time a sparse array is pushed on to the stack, store a magic scalar in the array itself, which av_exists and refto recognise as not existing. This means there is only a one-time cost for putting such arrays on the stack. It also means that deferred elements that live long enough don’t start pointing to the wrong array entry if the array gets shifted (or unshifted/spliced) in the mean time. Instead, the scalar is already in the array, so it cannot lose its place. This fix only applies when the array as a whole is pushed on to the stack, but it could be extended in future commits to apply to other places where we currently use deferred elements.
* store AV iterator as mg_len in more casesZefram2017-11-111-10/+10
| | | | | | | | | | | | | | | | | | | The iterator of an AV is an IV value attached to the AV via magic. It may be stored in the space used by mg_len, or it may be stored in separately allocated space referenced by mg_ptr. The former is more efficient, so should be preferred. The original code for AV iterators would use mg_len if IV was (the same size as) I32, because mg_len was of type I32. Since then mg_len has been increased to type SSize_t, but the conditional about how AV iterators are stored wasn't updated to match. As a result, on the now very common 64-bit builds we were missing out on the opportunity to use the more efficient form of storage. This commit updates the condition about how AV iterators are stored, to take account of the new type. In principle AV iterators ought to be of type SSize_t, and thus *always* storable as mg_len. But Perl_av_iter_p() is in the public API with its IV* return type, so there is a compatibility issue to address in changing that.
* av.c: silence compiler warningYves Orton2017-06-011-2/+3
| | | | | | | | | | av.c: In function ‘Perl_av_undef’: av.c:577:35: warning: ‘orig_ix’ may be used uninitialized in this function [-Wmaybe-uninitialized] PL_tmps_stack[orig_ix] = &PL_sv_undef; The warning is bogus, as we only use the orig_ix if real is true, and if real is true we will have set orig_ix. But it doesnt cost much to initialize it always and shut up the compiler.
* Change white space to avoid C++ deprecation warningKarl Williamson2016-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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.
* speed up AV and HV clearing/undeffingDavid Mitchell2016-10-261-12/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | av_clear(), av_undef(), hv_clear(), hv_undef() and av_make() all have similar guards along the lines of: ENTER; SAVEFREESV(SvREFCNT_inc_simple_NN(av)); ... do stuff ...; LEAVE; to stop the AV or HV leaking or being prematurely freed while processing its elements (e.g. FETCH() or DESTROY() might do something to it). Introducing an extra scope and calling leave_scope() is expensive. Instead, use a trick I introduced in my recent pp_assign() recoding: add the AV/HV to the temps stack, then at the end of the function, just PL_tmpx_ix-- if nothing else has been pushed on the tmps stack in the meantime, or replace the tmps stack slot with &PL_sv_undef otherwise (which doesn't care how many times its ref count gets decremented). This is efficient, and doesn't artificially extend the life of the SV like sv_2mortal() would. This commit makes this code around 5% faster: my @a; for my $i (1..3_000_000) { @a = (1,2,3); @a = (); } and this code around 3% faster: my %h; for my $i (1..3_000_000) { %h = qw(a 1 b 2); %h = (); }
* fixup some AV API pod descriptions.David Mitchell2016-09-271-11/+12
| | | | | | | | | | | | | | | | | | | In particular: * improve some of the "perl equivalent" entries; for example av_store() is *not* like $myarray[$key] = $val, since it replaces the stored SV with a different SV, rather than just updating the current SV's value. * Also change the "perl equivalent" variable names to match the function parameter names, e.g. $key rather than $idx. * Don't use 'delete' as a perl equivalent, since delete is discouraged on arrays. * You don't *have* to use av_store() to change undef values inserted by av_unshift; e.g. you could do av_fetch() then modify the returned undef SV; so just delete that sentence
* Revert "tmp fix for Bleadperl breaks Variable-Magic"David Mitchell2016-09-081-2/+1
| | | | | | | This reverts commit 8d168aaa014262c7f93944b76b84de99af3c5513. Variable-Magic 0.60 has been released, so this temp workaround is no longer required.
* tmp fix for Bleadperl breaks Variable-MagicDavid Mitchell2016-08-241-1/+2
| | | | | | | | | | | RT #128989 Prior to my commit v5.25.3-266-g1d7e644, in the absence of the SVs_RMG flag, av_fetch() used AvFILL() for -ve keys and AvFILLp() for positive keys. That commit changed it so they both use AvFILLp. This has broken Variable::Magic 0.59. As an interim measure, restore the old behaviour.
* av_fetch(): remove check for freed SVDavid Mitchell2016-08-191-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently av_fetch() has this extra test: if (AvREIFY(av) && SvIS_FREED(AvARRAY(av)[key])) { /* eg. @_ could have freed elts */ AvARRAY(av)[key] = NULL; /* 1/2 reify */ which basically says that if the array has the reify flag set (typically only @_ has this) and if the element being retrieved in it has been freed, then replace it with an undef value instead. This can be triggered with code like: sub f { $r = 0; my $var = $_[0]; } $r = do { my $x; \$x }; f($$r); which leaves $var as undef rather than causing a "panic: attempt to copy freed scalar". However, code like my ($var) = @_; *won't* get handled specially, and will still trigger the panic. It was added in 1996 as a result of this thread: From: Andreas Koenig <k@anna.in-berlin.de> Subject: SEGV with $_[0] and circular references Message-Id: <199608131528.RAA25965@anna.in-berlin.de> That was in the context of getting a SEGV - whereas now we get the "panic: attempt to copy freed scalar" instead. It was agreed in this thread that it could be removed: http://nntp.perl.org/group/perl.perl5.porters/239082
* av_fetch(): use less branches.David Mitchell2016-08-171-7/+14
| | | | | | | | | | | | | | | | | | | The code that handles negative array indexes and out-of-bounds negative indices used to require: 2 conditions for a +ve index 3 conditions for a -ve index After this commit, for the common case where the index is in bounds, it requires a single condition regardless of sign. For the less common case of out-of-bounds, it requires 2 conditions. Also, the one condition is more branch-predict friendly - it's whether the index is in bounds or not. Previously the first test was whether key < 0, and in code that does mixed signs, such as $a[0] + $a[-1], branch prediction could be tricky. It achieves this at the expense of a more complex expression for the key.
* av_fetch(): sprinkle UNLIKELY()David Mitchell2016-08-171-3/+3
|
* av_fetch(): optimise the negative index branch.David Mitchell2016-08-171-2/+4
| | | | | | For a negative index one conditional is redundant, since after determining that key < 0 and recomputing key as (AvFILLp(av) - key), key can't be > AvFILLp(av).
* av_fetch(): use AvFILLp rather than AvFILLDavid Mitchell2016-08-171-1/+1
| | | | | | | | | The point in the code which uses AvFILL will never be reached if the array is tied, so use AvFILLp insead, which directly accesses the xav_fill field. This only affects the $a[-N] branch: the $a[+N] branch already uses AvFILLp().
* av_fetch(): remove redundant conditionDavid Mitchell2016-08-171-3/+2
| | | | | At the point of testing for !AvARRAY(av)[key] if AvREIFY(av), it's already been confirmed that the array element isn't null.
* perlapi: Slight clarificationKarl Williamson2016-03-071-2/+2
| | | | | | | | | This changes to use 'transfer' to make clear that the reference count is unchanged. Some think that the previous wording 'take' is good as-is; some agree with me. Daniel Dragan has pointed out that 5 years ago I changed this line, while retaining 'take'. Given that 'transfer' is unambiguous to all, while 'take' is ambiguous to some, I'm making the change.
* Improve pod for [ah]v_(clear|undef)David Mitchell2015-10-201-7/+15
| | | | See [perl #117341].
* make EXTEND() and stack_grow() safe(r)David Mitchell2015-10-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes various issues around stack_grow() and its two main wrappers, EXTEND() and MEXTEND(). In particular it behaves very badly on systems with 32-bit pointers but 64-bit ints. One noticeable effect of this is commit is that various usages of EXTEND() etc will now start to give compiler warnings - usually because they're passing an unsigned N arg when it should be signed. This may indicate a logic error in the caller's code which needs fixing. This commit causes several such warnings to appear in core code, which will be fixed in the next commit. Essentially there are several potential false negatives in this basic code: if (PL_stack_max - p < (SSize_t)(n)) stack_grow(sp,p,(SSize_t)(n)); where it incorrectly skips the call to stack_grow() and then the caller tramples over the end of the stack because it assumes that it has in fact been extended. The value of N passed to stack_grow() can also potentially get truncated or wrapped. Note that the N arg of stack_grow() is SSize_t and EXTEND()'s N arg is documented as SSize_t. In earlier times, they were both ints. Significantly, this means that they are both signed, and always have been. In detail, the problems and their solutions are: 1) N is a signed value: if negative, it could be an indication of a caller's invalid logic or wrapping in the caller's code. This should trigger a panic. Make it so by adding an extra test to EXTEND() to always call stack_grow if negative, then add a check and panic in stack_grow() (and other places too). This extra test will be constant folded when EXTEND() is called with a literal N. 2) If the caller passes an unsigned value of N, then the comparison is between a signed and an unsigned value, leading to potential wrap-around. Casting N to SSize_t merely hides any compiler warnings, thus failing to alert the caller to a problem with their code. In addition, where sizeof(N) > sizeof(SSize_t), the cast may truncate N, again leading to false negatives. The solution is to remove the cast, and let the caller deal with any compiler warnings that result. 3) Similarly, casting stack_grow()'s N arg can hide any warnings issued by e.g. -Wconversion. So remove it. It still does the wrong thing if the caller uses a non-signed type (usually a panic in stack_grow()), but coders have slightly more chance of spotting issues at compile time now. 4) If sizeof(N) > sizeof(SSize_t), then the N arg to stack_grow() may get truncated or sign-swapped. Add a test for this (basically that N is too big to fit in a SSize_t); for simplicity, in this case just set N to -1 so that stack_grow() panics shortly afterwards. In platforms where this can't happen, the test is constant folded away. With all these changes, the macro now looks in essence like: if ( n < 0 || PL_stack_max - p < n) stack_grow(sp,p, (sizeof(n) > sizeof(SSize_t) && ((SSize_t)(n) != n) ? -1 : n));
* perlapi: Add some S<>Karl Williamson2015-09-031-7/+7
| | | | | so that these constructs appear on a single output line for reader convenience.
* 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.
* 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.
* avoid integer overflow in Perl_av_extend_guts()David Mitchell2014-12-311-3/+13
| | | | | | | | | | | | | | | | | There were two issues; first the 'overextend' algorithm (add a fifth of the current size to the requested size) could overflow, and secondly MEM_WRAP_CHECK_1() was being called with newmax+1, which could overflow if newmax happened to equal SSize_t_MAX. e.g. $a[0x7fffffffffffffff] = 1 $a[5] = 1; $a[0x7fffffffffffffff] = 1 could produce under ASan: av.c:133:16: runtime error: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long' av.c:170:7: runtime error: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long'
* Remove duplicate apidoc entriesDavid Mitchell2014-12-171-4/+0
| | | | | Modify apidoc.pl to warn about duplicate apidoc entries, and remove duplicates for av_tindex and toLOWER_LC
* Documentation typo fixRafael Garcia-Suarez2014-08-061-1/+1
|
* Remove or downgrade unnecessary dVAR.Jarkko Hietaniemi2014-06-251-16/+0
| | | | | | | | 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.
* PATCH: [perl #120386]: av_len documentationKarl Williamson2014-05-311-3/+8
| | | | I think I have incorporated everybody's concerns in this patch.
* refactor av_deleteDaniel Dragan2014-05-281-8/+8
| | | | | | | | Some bad code generation/bad optimization from VC caused me to clean this up. Dont write AvARRAY(av)[key] = NULL twice. It appears in 2 branches just as written VC asm wise. Don't call sv_2mortal on a NULL SV*. It works but less efficient. On VC2008 x64 -O1 this func dropped from 0x208 to 0x202 bytes of machine code after this patch.
* perlapi: Consistent spaces after dotsFather Chrysostomos2013-12-291-1/+1
| | | | plus some typo fixes. I probably changed some things in perlintern, too.
* Extend STRESS_REALLOC to move the stack with every EXTENDFather Chrysostomos2013-11-221-0/+9
| | | | | | This allows us easily to catch cases where the stack could move to a new memory address while code still holds pointers to the old loca- tion. Indeed, this causes test failures.
* [perl #120544] fix "goto" around var init error in av_extend_gutsDaniel Dragan2013-11-151-7/+14
| | | | | This fixes a Win32 Visual C 6 in C++ mode syntax error. See #120544 for the details.
* ｓｕｂ　ＮＥＧＡＴＩＶＥ＿ＩＮＤＩＣＥＳ； + ↵Father Chrysostomos2013-11-041-1/+2
| | | | | | | | | | | ＄ｔｉｅｄ［－１］ = crash This code in av.c, when trying to find $NEGATIVE_INDICES, was doing a direct stash element lookup--instead of going through the normal GV functions--and then expecting the returned value to be a GV. ‘sub NEGATIVE_INDICES’ creates a stash element that is a PV, not a GV, so it’s easy to make things crash.
* Use SSize_t for arraysFather Chrysostomos2013-08-251-18/+18
| | | | | | | | | | Make the array interface 64-bit safe by using SSize_t instead of I32 for array indices. This is based on a patch by Chip Salzenberg. This completes what the previous commit began when it changed av_extend.
* Use SSize_t when extending the stackFather Chrysostomos2013-08-251-4/+4
| | | | | | | | | | | | | | | | (I am referring to what is usually known simply as The Stack.) This partially fixes #119161. By casting the argument to int, we can end up truncating/wrapping it on 64-bit systems, so EXTEND(SP, 2147483648) translates into EXTEND(SP, -1), which does not extend the stack at all. Then writing to the stack in code like ()=1..1000000000000 goes past the end of allocated memory and crashes. I can’t really write a test for this, since instead of crashing it will use more memory than I have available (and then I’ll start for- getting things).
* [perl #7508] Use NULL for nonexistent array elemsFather Chrysostomos2013-08-201-32/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes bug #7508 and provides the groundwork for fixing several other bugs. Elements of @_ are aliased to the arguments, so that \$_[0] within sub foo will reference the same scalar as \$x if the sub is called as foo($x). &PL_sv_undef (the global read-only undef scalar returned by the ‘undef’ operator itself) was being used to represent nonexistent array elements. So the pattern would be broken for foo(undef), where \$_[0] would vivify a new $_[0] element, treating it as having been nonexistent. This also causes other problems with constants under ithreads (#105906) and causes a pending fix for another bug (#118691) to trig- ger this bug. This commit changes the internals to use a null pointer to represent a nonexistent element. This requires that Storable be changed to account for it. Also, IPC::Open3 was relying on the bug. So this commit patches both modules.
* Clarify av_shift API docsSteffen Mueller2013-07-201-3/+3
|
View Lorry Controller Status