summaryrefslogtreecommitdiff
path: root/op.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove empty "#ifdef"sTom Hukins2020-12-081-4/+0
|
* Fix unitialized warnings in S_pmtransNicolas R2020-11-061-1/+1
|
* autodoc.pl: Enhance apidoc_section featureKarl Williamson2020-11-061-9/+9
| | | | | | | | | | | This feature allows documentation destined for perlapi or perlintern to be split into sections of related functions, no matter where the documentation source is. Prior to this commit the line had to contain the exact text of the title of the section. Now it can be a $variable name that autodoc.pl expands to the title. It still has to be an exact match for the variable in autodoc, but now, the expanded text can be changed in autodoc alone, without other files needing to be updated at the same time.
* Perl_custom_op_get_field(): remove undef behaviourDavid Mitchell2020-10-301-8/+6
| | | | | | | | | | | | | | | | | | | Thus function has a couple a switches with default: NOT_REACHED; /* NOTREACHED */ but clang is complaining that the value returned by the function is undefined if those default branches are taken, since the 'any' variable doesn't get set in that path. Replace the NOTREACHED with a croak("panic: ..."). It's possible (albeit not intended) for Perl_custom_op_get_field() to be called with a 'field' arg which triggers the default case. So if this ever happens, make it clear that something has gone wrong, rather than just silently continuing on non-debugging builds. In any case, this shuts up clang.
* Document newSUB, newATTRSUBKarl Williamson2020-10-061-0/+11
|
* Document vload_moduleKarl Williamson2020-09-051-0/+3
|
* perlapi: capitalize 'op'Karl Williamson2020-09-051-1/+1
|
* 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.
* Change some =head1 to apidoc_section linesKarl Williamson2020-09-041-8/+8
| | | | | apidoc_section is slightly favored over head1, as it is known only to autodoc, and can't be confused with real pod.
* Document a bunch of foo_nocontext functionsKarl Williamson2020-08-231-0/+5
| | | | These just refer to foo's pod, with an explanation of 'nocontext'
* Use av_top_index() instead of av_tindex()Karl Williamson2020-08-191-1/+1
| | | | | | | I was never happy with this short form, and other people weren't either. Now that most things are better expressed in terms of av_count, convert the few remaining items that are clearer when referring to an index into using the fully spelled out form
* list assign in list context was over-optimisingDavid Mitchell2020-08-111-3/+7
| | | | | | | | | | | | | | | | | | | GH #17816 This code: my $x = 1; print (($x, undef) = (2 => $x)); was printing "22" when it should have been printing "21". An optimisation skips the 'common values on both sides' test when the LHS of an assign only contains a single var; as the example above shows, this is not sufficient. This was broken by v5.23.1-202-g808ce55782 This commit fixes it by counting undef's on the LHS towards the var count if they don't appear first.
* add a default enabled feature "multidimensional"Tony Cook2020-08-101-3/+11
| | | | | | Like "indirect" this feature is enabled by default and enables the perl4 hash-based multidimensional array emulation documented under $; in perlvar.
* re-work opslab handling to avoid non-portable alignment assumptionsTony Cook2020-07-301-40/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #17871 The op slab allocator code made the assumption that since OP and hence OPSLOT contain pointers, the base of each of those would be an integral number of sizeof(pointer) (pointer units) from the beginning of OPSLAB. This assumption is non-portable, and broke calculating the location of the slab based on the address of the op slot and the op slot offset on m68k platforms. To avoid that, this change now stores the opslot_offset as the offset in pointer units from the beginning of opslab_slots rather than from the beginning of the slab. If alignment on a pointer boundary for OPs is required, the compiler will align opslab_opslots and since we work in pointer units from there, any allocated op slots will also be aligned. If we assume PADOFFSET is no larger than a pointer and requires no stricter alignment and structures in themselves have no stricter alignment requirements then since we work in pointer units all core OP structures should have sufficient alignment (if this isn't true, then it's not a new problem, and not the problem I'm trying to solve here.) I haven't been able to test this on m68k hardware (the emulator I tried to use can't maintain a network connection.)
* Remove use of dVAR in coreDagfinn Ilmari Mannsåker2020-07-201-60/+0
| | | | | It only does anything under PERL_GLOBAL_STRUCT, which is gone. Keep the dNOOP defintion for CPAN back-compat
* Fix tr/// determination of inplace editing for EBCDICKarl Williamson2020-05-271-20/+38
| | | | | | | | | | | I realized as a result of fixing GH #17654, that the code didn't properly decide if a tr/// can be done in-place on EBCDIC platforms. Since we didn't have an EBCDIC smoker at the time, I couldn't be sure that the fix actually worked. Now that we do have a smoker, I have successfully tested it. This patch is constructed so that the code generated on non-EBCDIC platforms should not be changed by it.
* Fix a bunch of repeated-word typosDagfinn Ilmari Mannsåker2020-05-221-8/+6
| | | | | Mostly in comments and docs, but some in diagnostic messages and one case of 'or die die'.
* Revert "avoid identical stack traces"David Mitchell2020-04-271-23/+1
| | | | This reverts commit f2f32cd638746f538da6db804dab6dd54e654f30.
* Revert "fixup to "avoid identical stack traces" - try 2"David Mitchell2020-04-271-3/+4
| | | | This reverts commit ad89278aa25475fb03971aec66692e18e35d9c07.
* op.c: Add, clarify commentsKarl Williamson2020-04-021-30/+48
|
* tr/abc/de/: Properly handle longer lhs in in-place calcKarl Williamson2020-04-021-1/+6
| | | | | | | | | | | | | | | | | | | | | | A tr/// can be done in-place if the target string doesn't contain a character whose transliterated representation is longer than the original. Otherwise, writing the new value would destroy the next character we need to read. In general, we can't know if a particular string contains such a character without keeping a list of the problematic characters, and scanning it ahead of time for occurrences of those. Instead, we determine at compilation time if, for a given transliteration, if there exists any possible target string that could have an overwriting problem. If none exist, we edit in place. Otherwise, we first make a copy. Prior to this commit, the code failed to account for the case where the rhs is shorter than the left, so that any unmatched lhs characters map to the final rhs one. The reason the code didn't consider this is that I didn't think of this possibility when writing it. This fixes #17654 and #17643
* fix PERL_GLOBAL_STRUCT_PRIVATE buildsDavid Mitchell2020-03-201-0/+4
| | | | | Sprinkle some dVAR pixie dust to fix recent bitrot on that build configuration.
* fixup to "avoid identical stack traces" - try 2David Mitchell2020-03-181-4/+3
| | | | | | | | | | | | | | | | | | | GH #15109, #17567 [ this commit was originally applied as v5.31.9-121-gfb8188b84d, but was quickly reverted by v5.31.9-124-g6311900a66. I'm now -re-applying it, but with a 'SAVEFREEOP(PL_curcop)' added, which was missing from the original commit. ] My original fix for this issue, v5.31.6-141-gf2f32cd638 made a shallow copy of &PL_compiling. However, for non-default warning bits, this made two COPs share the malloced() cop_warnings, and bad things ensured. In particular this was flagged up in: GH #17567: "BBC: AYOUNG/OpenVZ-0.01.tar.gz" The fix in this commit is to do a deep copy of the COP using newSTATEOP().
* op.c: change Optype to I32 for cmpchain functionsYves Orton2020-03-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Optype appears to be almost completely unused, and on Win32 builds we saw warnings from the cmpchain patches: perly.y(1063) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data perly.y(1065) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data perly.y(1079) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data perly.y(1081) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data Reviewing the code I noticed that functions like Perl_newBINOP() have an I32 type argument, and functions like OpTYPE_set() coerce such arguments into type OPCODE: #define OpTYPE_set(o,type) \ STMT_START { \ o->op_type = (OPCODE)type; \ o->op_ppaddr = PL_ppaddr[type]; \ } STMT_END this patch changes the signature to the new cmpchain functions so that they do they same, and change the type for storage for op_type values to also use OPCODE like most of the other op.c code.
* chained comparisonsZefram2020-03-121-0/+115
|
* Revert "fixup to "avoid identical stack traces""Nicolas R2020-03-121-2/+4
| | | | | | | | | | | | | | This reverts commit fb8188b84d8a8f34f90aa9a8d9837892967f6b93. Unfortunately this is causing some errors during global destruction like: Unbalanced string table refcount: (1) for "open_IN" during global destruction It seems to be flapping, and recompiling Perl could see or not the issue. Upstream-URL: https://github.com/Perl/perl5/commit/fb8188b84d8a8f34f90aa9a8d9837892967f6b93
* fixup to "avoid identical stack traces"David Mitchell2020-03-121-4/+2
| | | | | | | | | | | | | | GH #15109, #17567 My original fix for this issue, v5.31.6-141-gf2f32cd638 made a shallow copy of &PL_compiling. However, for non-default warning bits, this made two COPs share the malloced() cop_warnings, and bad things ensured. In particular this was flagged up in: GH #17567: "BBC: AYOUNG/OpenVZ-0.01.tar.gz" The fix in this commit is to do a deep copy of the COP using newSTATEOP().
* op.c: S_fold_constants_eval can't be inlinedKarl Williamson2020-03-111-2/+3
| | | | Because it uses setjmp, is what g++ says
* make freed op re-use closer to O(1)Tony Cook2020-03-021-20/+59
| | | | | | | | | | | | | | | | previously freed ops were stored as one singly linked list, and a failed search for a free op to re-use could potentially search that entire list, making freed op lookups O(number of freed ops), or given that the number of freed ops is roughly proportional to program size, making the total cost of freed op handling roughly O((program size)**2). This was bad. This change makes opslab_freed into an array of linked list heads, one per op size. Since in a practical sense the number of op sizes should remain small, and insertion is amortized O(1), this makes freed op management now roughly O(program size). fixes #17555
* multiconcat: keep assign for 'local $foo = "..."'David Mitchell2020-02-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In something like local $~ = "$~X"; i.e. where localising a magic variable whose previous value should be used as part of a string concat on the RHS, don't fold the assign into the multiconcat op. Otherwise the code execution path looks a bit like: local($~) = undef; multiconcat($~, $~, "X"); [ where multiconcat's args are (target, arg1, arg2,....) ] and thus multiconcat sees an undef arg. By leaving the assign out of the multiconcat, code execution now looks like my $targ; multiconcat($targ, $~, "X"); local($~) = $targ; See http://nntp.perl.org/group/perl.perl5.porters/256898, "Bug in format introduced in 5.27.6". Although the bug only appears with magic vars, this patch pessimises all forms of 'local $foo = "..."', 'local $foo{bar} = "..."' etc. Strictly speaking the bug occurs because with 'local' you end up with two SVs (the saved one and the one currently in the glob) which both have the same container magic and where mg_set()ing one changes the mg_get() value of the other. Thus, vars like $!. One of the two SVs becomes an arg of multiconcat, the other becomes its target. Part of localising the target SV (before multiconcat is called) wipes the value of the arg SV.
* op.c: hoist first-pass logic out of loop in pmtrans()Hugo van der Sanden2020-02-011-21/+18
| | | | Mainly to avoid gcc warnings that found the logic too complex to follow.
* op.c: balance braces in #if 0 sectionHugo van der Sanden2020-02-011-0/+1
| | | | | Balance the braces so we can bounce to matching braces for the rest of S_pmtrans.
* Local variable 'o' hides a parameter of the same nameJames E Keenan2020-01-291-17/+17
| | | | | | | | | | | | | | | LGTM static code analysis identified declaration of 'o' in a scope where a variable of the same name had already been declared in an enclosing scope. Simply renaming the variable within the inner scope did not work (extensive segfaults). Tony Cook identified problem: In inner scope we were using macro cLISTOPo, which implicitly modifies 'o'. Since cLISTOPo is nothing more than macro cLISTOPx() with 'o' provided as the argument, we can resolve the problem by using cLISTOPx() with a better named variable -- in this case, 'child'. Reference: https://lgtm.com/projects/g/Perl/perl5/snapshot/9b2028e54156e4dbcc7a57bbd72e1b00a2e0ce39/files/op.c?sort=name&dir=ASC&mode=heatmap#x9b0ebeab3d026530:1
* Harmonize whitespace.James E Keenan2020-01-291-34/+34
|
* More descriptive variable nameJames E Keenan2020-01-281-8/+8
| | | | | Per discussion with Tony Cook, rename one variable used in commit 5162664ad5f (p.r. 17368) on Dec 16 2019.
* OP_MULTIDEREF: avoid trailing null aux byteDavid Mitchell2020-01-021-8/+13
| | | | | | | | | | | | | | | | | | | | | | | GH #17301 The aux array in an OP_MULTIDEREF op consists of an action word containing as many actions as will fit shifted together, followed by words containing the arguments for those actions. Then another action word, and so on. The code in S_maybe_multideref() which creates those ops was reserving a new slot in the aux array for a new action word when the old one became full. If it then turned out that no more actions were needed, this extra slot was harmlessly filled with a zero. However it turns out that the B::UNOP_AUX::aux_list() introspection method would, under those circumstances, claim to have returned one more SV on the stack than it actually had, leading to SEGVs etc. I could have fixed aux_list() directly to cope with an extra null word, but instead I did the more general fix of ensuring that S_maybe_multideref() never adds an extra null word in the first place. The test added to ext/B/t/b.t fails before this commit; the new test in lib/B/Deparse.t doesn't, but was added for completeness.
* op.c: Fix typo in commentKarl Williamson2019-12-291-1/+1
|
* op.c: Use %NVgf instead of %g format in debug stmtKarl Williamson2019-12-291-1/+1
| | | | The former is portable to different sized doubles.
* Add memCHRs() macro and use itKarl Williamson2019-12-181-5/+5
| | | | | | | This replaces strchr("list", c) calls throughout the core. They don't work properly when 'c' is a NUL, returning the position of the terminating NUL in "list" instead of failure. This could lead to segfaults or even security issues.
* Note that certain flags are documentedKarl Williamson2019-12-171-0/+13
| | | | | | | | | | | This is useful in Devel::PPPort for generating its api-info data. That useful feature of D:P allows someone to find out what was the first release of Perl to have a function, macro, or flag. And whether using ppport.h backports it further. I went through apidoc.pod and looked for flags that were documented but that D:P didn't know about. This commit adds entries for each so that D:P can find them.
* Local variable 'o' hides a parameter of the same name.James E Keenan2019-12-161-18/+18
| | | | | | | This sub-optimal code has been reported by LGTM static code analysis. There are actually two such instances very close to one another within op.c. This commit handles only the first of them, renaming a variable and regularizing the indents to make the relevant scope more self-evident.
* avoid identical stack tracesDavid Mitchell2019-12-131-1/+23
| | | | | | | | | | | | | | | | | | | | | GH #15109 The output of caller() (e.g. as produced by carp::Confess) produces multiple identical outputs when within a nested use/require. This is because at the time of calling the 'BEGIN { require ... }', PL_curcop is set to &PL_compiling, which is a fixed buffer within the interpreter, whose individual file and line fields are saved and restored when doing a new require/eval. This means that within the innermost require, PL_compiling has file:lineno of the innermost source file, and multiple saved PL_curcop values in the context stack frames all point to the same &PL_copmpiling. So all levels of the stack trace appear to come from the innermost file. This commit fixes this (after a fashion) by, at the start of calling a BEGIN, making PL_curcop point to a temporary copy of PL_compiling instead. This is all a bit of a hack.
* Add the `isa` operatorPaul "LeoNerd" Evans2019-12-091-0/+16
| | | | | | | | | | | | | | | | | | Adds a new infix operator named `isa`, with the semantics that $x isa SomeClass is true if and only if `$x` is a blessed object reference that is either `SomeClass` directly, or includes the class somewhere in its @ISA hierarchy. It is false without warning or error for non-references or non-blessed references. This operator respects `->isa` method overloading, and is intended to replace boilerplate code such as use Scalar::Util 'blessed'; blessed($x) and $x->isa("SomeClass")
* Clean up -Dy debuggingKarl Williamson2019-11-181-8/+16
| | | | | Commit 5d7580af4b14229eafb27db9b7a34b8b918876b4 didn't have it quite right.
* Fix tr/// for 32 bit platforms with 64bit intsKarl Williamson2019-11-181-12/+15
| | | | | Various variables were declared wrongly to be Size_t, instead of the needed 'UV'.
* op.c: Rmv redundant line in tr/// tableKarl Williamson2019-11-181-1/+0
| | | | | The line was a relict of debugging. I don't know if this could lead to a bug or not, but it certainly did not belong.
* Add -Dy debugging of tr///, y///Karl Williamson2019-11-171-0/+54
|
* doop.c, op.c: Silence some compiler warningsKarl Williamson2019-11-151-4/+4
|
* op.c: Move #endifKarl Williamson2019-11-111-2/+3
| | | | Otherwise this fails to compile on EBCDIC
* PATCH: gh#17227 heap-buffer-overflowKarl Williamson2019-11-081-1/+13
| | | | | | | | | There were two problems this uncovered. One was that a floating point expression with both operands ints truncated before becoming floating. One operand needs to be floating. The second is that the expansion of a non-UTF-8 byte needs to be considered based on non-UTF-8, rather than its UTF-8 representation.
View Lorry Controller Status