summaryrefslogtreecommitdiff
path: root/mg.c
Commit message (Collapse)AuthorAgeFilesLines
* don't taint $$ determined by getpid()Zefram2012-02-251-1/+4
| | | | | | Reading $$ in a tainted expression was tainting the internal sv_setiv() on $$. Since the value being set came directly from getpid(), it's always safe, so override the tainting there. Fixes [perl #109688].
* Fix typo in 985213f2fede57.Craig A. Berry2012-02-181-1/+1
| | | | Which broke the build on both VMS and Win32.
* Remove gete?[ug]id cachingÆvar Arnfjörð Bjarmason2012-02-181-38/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we cache the UID/GID and effective UID/GID similarly to how we used to cache getpid() before v5.14.0-251-g0e21945. Remove this magical behavior in favor of always calling getpid(), getgid() etc. This resolves RT #96208. A minimal testcase for this is the following by Leon Timmermans attached to RT #96208: eval { require 'syscall.ph'; 1 } or eval { require 'sys/syscall.ph'; 1 } or die $@; if (syscall(&SYS_setuid, $ARGV[0] + 0 || 1000) >= 0 or die "$!") { printf "\$< = %d, getuid = %d\n", $<, syscall(&SYS_getuid); } I.e. if we call the sete?[ug]id() functions unbeknownst to perl the $<, $>, $( and $) variables won't be updated. This results in the same sort of issues we had with $$ before v5.14.0-251-g0e21945, and getppid() before my v5.15.7-407-gd7c042c patch. I'm completely eliminating the PL_egid, PL_euid, PL_gid and PL_uid variables as part of this patch, this will break some CPAN modules, but it'll be really easy before the v5.16.0 final to reinstate them. I'd like to remove them to see what breaks, and how easy it is to fix it. These variables are not part of the public API, and the modules using them could either use the Perl_gete?[ug]id() functions or are working around the bug I'm fixing with this commit. The new PL_delaymagic_(egid|euid|gid|uid) variables I'm adding are *only* intended to be used internally in the interpreter to facilitate the delaymagic in Perl_pp_sassign. There's probably some way not to export these to programs that embed perl, but I haven't found out how to do that.
* Allow ${^WARNING_BITS} to turn off lexical warningsFather Chrysostomos2012-01-261-8/+4
| | | | | | | | | | | | | | Various magical modules copy hints from one scope to another. But copying ${^WARNING_BITS} doesn’t always copy the same hints. If lexi- cal warnings are not on at all, ${^WARNING_BITS} returns a different value depending on the current value of $^W. Setting ${^WARNING_BITS} to its own value when $^W is true will stop $^W from being able to control the warnings in the current compilation scope. Setting ${^WARNING_BITS} to its own value when $^W is false causes even default warnings to be suppressed. This commit makes undef a special value that represents the default state, in which $^W controls warnings.
* [perl #67490] Don’t call DELETE on scalar-tied elemFather Chrysostomos2012-01-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This little snippet: sub TIESCALAR{bless[]} sub STORE{} tie $^H{foo}, ''; $^H{foo} = 1; delete $^H{foo}; dies with ‘Can't locate object method "DELETE"...’. This bug was introduced for %^H by commit b3ca2e834c, but it is actu- ally an older bug that already affected %ENV before that. Clear-magic on a scalar is only called when it is an element of a mag- ical aggregate. For hashes, this clear-magic is called whenever the hash itself is RMAGICAL. Tied scalars and elements of tied aggregates use the same magic vta- ble, under the assumption that mg_clear will never be called on a tied scalar. That assumption is wrong. Commit b3ca2e834c is the one that made %^H magical, which is why it caused this problem for %^H. The obvious solution, giving tied scalars their own vtable, is not as simple as it sounds, because then tied scalars are no longer RMAGICAL, and at least some of the tie code assumes that they are. So the easiest fix is to skip the DELETE call in Perl_magic_clearpack if the type of magic is PERL_MAGIC_tiedscalar.
* Don’t iterate through magic with local $_Father Chrysostomos2012-01-041-1/+3
| | | | | If we are going to skip all set-magic when restoring a localised tied $_, there’s no point in looping through it.
* [perl #105912] local $_ should not FETCHFather Chrysostomos2012-01-031-0/+2
| | | | | This commit finishes the work of 658a9f3 by skipping FETCH as well as STORE during local($_).
* [perl #29070] Add vstring set-magicFather Chrysostomos2011-12-231-0/+13
| | | | | | | | | | | | Some operators, like pp_complement, assign their argument to TARG (which copies vstring magic), modify it in place, and then call set- magic. That’s supposed to work, but vstring magic was remaining as it was, such that ~v7 would still be treated as "v7" by vstring-aware code, even though the resulting string is not "\7". This commit adds vstring set-magic that checks to see whether the pv still matches the vstring. It cannot simply free the vstring magic, as that would prevent $x=v0 from working.
* Disable $[ under 5.16Father Chrysostomos2011-12-151-0/+4
| | | | | | | | | | | | | | | | | | | | | This adds the array_base feature to feature.pm Perl_feature_is_enabled has been modified to use PL_curcop, rather than PL_hintgv, so it can work with run-time hints as well. (PL_curcop holds the current state op at run time, and &PL_compiling at compile time, so it works for both.) The hints in $^H are not stored in the same place at compile time and run time, so the FEATURE_IS_ENABLED macro has been modified to check first whether PL_curop == &PL_compiling. Since array_base is on by default with no hint for it in %^H, it is a ‘negative’ feature, whose entry in %^H turns it off. feature.pm has been modified to support such negative features. The new FEATURE_IS_ENABLED_d can check whether such default features are enabled. This does make things less efficient, as every version declaration now loads feature.pm to disable all features (including turning off array_base, which entails adding an entry to %^H) before loading the new bundle. I have plans to make this more efficient.
* Adjust substr offsets when using, not when creating, lvalueFather Chrysostomos2011-12-041-8/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When substr() occurs in potential lvalue context, the offsets are adjusted to the current string (negative being converted to positive, lengths reaching beyond the end of the string being shortened, etc.) as soon as the special lvalue to be returned is created. When that lvalue is assigned to, the original scalar is stringified once more. That implementation results in two bugs: 1) Fetch is called twice in a simple substr() assignment (except in void context, due to the special optimisation of commit 24fcb59fc). 2) These two calls are not equivalent: $SIG{__WARN__} = sub { warn "w ",shift}; sub myprint { print @_; $_[0] = 1 } print substr("", 2); myprint substr("", 2); The second one dies. The first one only warns. That’s mean. The error is also wrong, sometimes, if the original string is going to get longer before the substr lvalue is actually used. The behaviour of \substr($str, -1) if $str changes length is com- pletely undocumented. Before 5.10, it was documented as being unreli- able and subject to change. What this commit does is make the lvalue returned by substr remember the original arguments and only adjust the offsets when the assign- ment happens. This means that the following now prints z, instead of xyz (which is actually what I would expect): $str = "a"; $substr = \substr($str,-1); $str = "xyz"; print $substr;
* Don’t coerce $x immediately in foo(substr $x...)Father Chrysostomos2011-11-261-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This program: #!perl -l sub myprint { print @_ } print substr *foo, 1; myprint substr *foo, 1; produces: main::foo Can't coerce GLOB to string in substr at - line 4. Ouch! I would expect \substr simply to give me a scalar that peeks into the original string, but without modifying the original until the return value of \substr is actually assigned to. But it turns out that it coerces the original into a string immedi- ately, unless it’s GMAGICAL. I find the exception for magical varia- ble rather befuddling. I can only imagine it was for efficency (since the stringified form will be overwritten when magic_setsubstr calls SvGETMAGIC), but that doesn’t make sense as the original variable can itself be modified between the return of the special lvalue and the assignment to that lvalue. Since magic_setsubstr itself coerces the variable into a string upon assignment to the lvalue, we can just remove the coercion code from pp_substr. But that causes double uninitialized warnings in cases like substr($undef, 0,0) = "lrep". That happens because pp_substr is still stringifying the variable (but without modifying it). It has to do that, as it looks at the length of the original string and accordingly adjusts the offsets stored in the lvalue if they are negative or if they extend beyond the end of the string. So this commit takes the simple route of avoiding the warning in pp_substr by only stringifying a variable that is SvOK if called in lvalue context. Hence, assignment to substr($tied...) will continue to call FETCH twice, but that is not a new bug. The ideal solution would be for the offsets to be translated in mg.c, rather than in pp_substr. But that would be a more involved change (including most of this commit, which is therefore not wasted) with potential backward-compatibility issue with negative numbers. A side effect it that the ‘Attempt to use reference as lvalue in substr’ warning now occurs during the assignment to the substr lvalue, rather that substr itself. This means it occurs even for tied varia- bles, so things are now more consistent. The example at the beginning could still croak if the glob were replaced with a null string, so this commit only partially allevi- ates the pain.
* Fix third argument to setresgid call while setting $(.Leon Timmermans2011-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | [Committer's note: discussion on perl5-security-report concluded that exploitability was low to nonexistent because any system that has setresgid but not setregid will pretend to have the latter and define it in terms of the former (see "#ifndef HAS_SETREGID" in perl.h). But the bug should be fixed in case that code gets exposed in the future. The approach taken in perl.h was also called into question and may elicit further discussion and patching.] Note: bug this only affects systems that have setresgid but not setregid (since that codepath prefers the latter over the former). To the best of my knowledge, no such systems exists (nor would it make much sense) so this bug is probably not exploitable, but I can't guarantee that. When the effective group is set using setresgid, it does this: setresgid((Gid_t)PL_gid, (Gid_t)-1, (Gid_t) 1); That last 1 should have been a -1. Instead of leaving the saved GID unchanged it sets it to to 1. This means privileges are not permanently dropped, but instead the GID is set to 1 (if possible). The program can thereafter change it's effective and real GIDs to 1.
* Reimplement $[ as a moduleFather Chrysostomos2011-10-211-4/+0
| | | | | | | | | | | | | | | | | This commit reimplements $[ using PL_check hooks, custom pp func- tions and ties. Outside of its compile-time use, $[ is now parsed as a simple varia- ble, so function calls like foo($[) are permitted, which was not the case with the former implementation removed by e1dccc0. I consider that a bug fix. The ‘That use of $[ is unsupported’ errors are out of necessity deferred to run-time and implemented by a tied $[. Indices between 0 and the array base are now treated consistently, as are indices between a negative array base and zero. That, too, is a bug fix.
* whichsig nul-cleanup.Brian Fraser2011-10-061-15/+42
| | | | | This adds _pv, _pvn, and _pv versions of whichsig() in mg.c, which get both kill "NAME" and %SIG lookup nul-clean.
* Remove if(isGV_with_GP(PL_defoutgv)) checks from mg.cFather Chrysostomos2011-09-121-24/+12
| | | | | | | | | | | | | | | Commit 099be4f1d added code to cope with this: my $x = *STDERR; select($x); $x = 1; which would cause PL_defoutgv to hold something other than a GV, resulting in various crashes. Commit 2acc3314 changed the way rv2gv works on fake globs, and inad- vertently fixed this problem, too, so PL_defoutgv can no longer end up holding something other than a GV. So the code that checks if(isGV_with_GP(PL_defoutgv)) can go.
* remove index offsetting ($[)Zefram2011-09-091-6/+7
| | | | | | $[ remains as a variable. It no longer has compile-time magic. At runtime, it always reads as zero, accepts a write of zero, but dies on writing any other value.
* make assign to $^A update FmLINESDavid Mitchell2011-07-201-0/+8
| | | | | | | | | | | | | | | Currently assigning to $^A updates the string in PL_bodytarget, but doesn't update FmLINES(PL_bodytarget). This can cause later writes to get confused about how many lines have been output, and was causing write.t to fail test 418 under miniperl. (Only under miniperl, because skipping some tests under miniperl affected how $^A's content and line count got messed up). Fix this by updating FmLINES(PL_bodytarget) when $^A is set. (Also fixes a TODO test which was failing due to 'local $^A' in earlier tests)
* Clean up magic_methcall docsFather Chrysostomos2011-07-161-7/+14
| | | | | | | | | | | | | | | | | | | | | | | This is rather unsightly, don’t you think? magic_methcall Invoke a magic method (like FETCH). * sv and mg are the tied thingy and the tie magic; * meth is the name of the method to call; * argc is the number of args (in addition to $self) to pass to the method; the args themselves are any values following the argc argument. * flags: G_DISCARD: invoke method with G_DISCARD flag and don’t return a value G_UNDEF_FILL: fill the stack with argc pointers to PL_sv_undef. Returns the SV (if any) returned by the method, or NULL on failure. (That’s the ‘rendered’ nroff output.) I would have used =over/=item/=back, but autodoc.pl doesn’t seem to like those.
* Split out study magic from pos magic.Nicholas Clark2011-07-011-2/+4
| | | | | | study uses magic to call SvSCREAM_off() if the scalar is modified. Allocate it its own magic type ('G' for now - pos magic is 'g'). Share the same "set" routine and vtable as regexp/bm/fm (setregxp and vtbl_regexp).
* Revert "pos in lvalue context now returns a PVMG instead of a PVLV."Father Chrysostomos2011-06-161-2/+4
| | | | | | | | | This reverts commit 571f0e8653a532c34edde36e797ecba446978b1c. I’m afraid I have to revert this, as it does not modify sv_reftype accordingly, and doing so would add *more* complexity (the opposite of what that commit was trying to achieve) and slow down ref() at run time, by making it search for pos magic.
* pos in lvalue context now returns a PVMG instead of a PVLV.Nicholas Clark2011-06-141-4/+2
| | | | | Store the target SV in mg_obj, instead of LvTARG(). This slightly reduces both code complexity and runtime memory use.
* Make $$ writable, but still magicalFather Chrysostomos2011-06-131-1/+18
| | | | | | | | | | | | | | | | This commit makes $$ writable again, as it was in 5.6, while preserv- ing the magical pid-fetching added recently (post-5.14.0) by com- mit 0e219455. It does this by following Aristotle Pagaltzis’ brilliant suggestion in <20110609145148.GD8471@klangraum.plasmasturm.org>; namely, to store the PID in magic when $$ is written to, so that get-magic can detect whether a fork() has occurred and reset $$ accordingly. This makes it seem as though the fork() code sets $$ itself (which it used to before 0e219455), while even working when C code outside of perl’s control calls fork(). This restores compatibility with DBIx::Connector and PPerl.
* Store a flag for container/value magic in PL_magic_data.Nicholas Clark2011-06-111-38/+3
| | | | Use this to replace S_is_container_magic() in mg.c with a direct lookup.
* Stop localised ties from becoming ro when COWFather Chrysostomos2011-06-041-1/+1
|
* Turn $$ into a magical readonly variable that always fetches getpid() ↵Max Maischein2011-05-221-0/+4
| | | | | | | | | | | instead of caching it The intent is that by not caching $$, we eliminate one opportunity for bugs: If one embeds Perl or uses XS and calls fork(3) from C, Perls notion of $$ may go out of sync with what getpid() returns. By always fetching the value of $$ via getpid(), this bug opportunity is eliminated. The overhead of always fetching $$ should be small and is likely only used for tempfile creation, which should be dwarfed by file system accesses.
* Remove PERL_UNUSED_ARG() from Perl_magic_clearsig(), missed by 179c85a2d774d3beNicholas Clark2011-05-191-1/+0
|
* Clean: Actually use HvUSEDKEYS() instead of HvKEYS()Michael Witten2011-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This: commit 8aacddc1ea3837f8f1a911d90c644451fc7cfc86 Author: Nick Ing-Simmons <nik@tiuk.ti.com> Date: Tue Dec 18 15:55:22 2001 +0000 Tidied version of Jeffrey Friedl's <jfriedl@yahoo.com> restricted hashes - added delete of READONLY value inhibit & test for same - re-tabbed p4raw-id: //depot/perlio@13760 essentially deprecated HvKEYS() in favor of HvUSEDKEYS(); this is explained in line 144 (now 313) of file `hv.h': /* * HvKEYS gets the number of keys that actually exist(), and is provided * for backwards compatibility with old XS code. The core uses HvUSEDKEYS * (keys, excluding placeholdes) and HvTOTALKEYS (including placeholders) */ This commit simply puts that into practice, and is equivalent to running the following (at least with a35ef416833511da752c4b5b836b7a8915712aab checked out): git grep -l HvKEYS | sed /hv.h/d | xargs sed -i s/HvKEYS/HvUSEDKEYS/ Notice that HvKEYS is currently just an alias for HvUSEDKEYS: $ git show a35ef416833511da752c4b5b836b7a8915712aab:hv.h | sed -n 318p #define HvKEYS(hv) HvUSEDKEYS(hv) According to `make tests': All tests successful.
* S_mg_findext_flags wasn't declared staticGisle Aas2011-05-181-1/+1
|
* Store the compiled format in mg_ptr instead of after SvCUR() - fixes RT #89218Nicholas Clark2011-05-181-1/+0
| | | | | | | | | | | | | | | | | | | | | Formats are compiled down to a sequence of U32 opcodes in doparseform(). Previously the block of opcodes was stored in the buffer of SvPVX() after the raw string by extending the buffer, and calculating the first U32 aligned address after SvCUR(). A flag bit on the scalar was set to signal this hackery, tested with SvCOMPILED() The flag bit used happened to be the same as one of the two used by to signal Boyer-Moore compiled scalars. The assumption was that no scalar can be used for both. Unfortunately, this isn't quite true. Given that the scalar is alway upgraded to PVMG to add PERL_MAGIC_fm magic, to clear the cached compiled version, there's no extra memory cost in using mg_ptr in the MAGIC struct to point directly to the block of U32 opcodes. The test for "is there a compiled version" can switch to mg_find(..., PERL_MAGIC_fm) returning a pointer, and the use of a flag bit abolished. Retain SvCOMPILED() and SvCOMPILED_{on,off}() as compatibility for XS code on CPAN - the first is always 0, the other two now no-ops.
* make mg_clear() et al behave when RC==0David Mitchell2011-04-071-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | The functions S_save_magic() and S_restore_magic(), which are called by mg_get(), mg_set(), mg_length(), mg_size() and mg_clear(), are not robust when called with an SV whose reference count is zero. Basically, one of the actions of S_save_magic() is to temporarily increase the refcount of the SV, and then for S_restore_magic() to reduce it again at the end, so that if any of the magic functions called inbetween decrease the count, it won't be prematurely freed. However, if the count starts at zero, then bumping it up and bringing it back down to zero, triggers a spurious second freeing. So, if its zero, just skip the whole bumping thing. Now, we shouldn't really be calling these functions will a zero-refcount SV, but these things happen, and its best to be robust. In particular, this fixes RT #87860, which was ultimately triggered by a bug in Set::Object 1.28 that managed to create an HV with null SvMAGIC field, but with the RMG flag set. When freeing that HV, sv_clear() skips doing mg_free() because SvMAGIC is null, whereas later it calls Perl_hv_undef_flags, which calls mg_clear() because it uses the test SvRMAGICAL(hv) (which is true).
* #84774: local $_ calls STORE when $_ is aliased to a tied hash elementJan Dubois2011-03-201-1/+4
| | | | | | local($_) will now strip all magic from $_, so that it is always safe to localize $_, regardless what kind of special (or tied) variable it may have been aliased to.
* Perl_sighandler: only inc SS_ix for unsafe signalsDavid Mitchell2011-03-191-9/+13
| | | | | | | | | Perl_sighandler currently increments the savestack by 5 before running a signal handler, to avoid messing with a partially completed SS push operation that's been interrupted. This is irrelevant for safe signals, so make this action conditional on unsafe signals only.
* In signal handler, don't inc stack pointersDavid Mitchell2011-03-191-14/+1
| | | | | | | | | | | | | | | | | | | | | | | | In Perl_sighandler, we currently increment PL_markstack_ptr and PL_scopestack_ix. This was added back in 1997 in the era of unsafe signals, to make them slightly less unsafe. The idea presumably was to stop signal handlers inadvertently corrupting the top element of each stack. However, given that the normal method of pushing something onto those stacks is to increment the pointer before pushing the value, I don't see how that can happen. The downside of this is that an uninitialised or stale value can be left in the 'hole' left on these stacks. When exiting from a signal handler via exit(), these holes can be read and corruption occur, while stack unwinding is taking place. The ordering of things means we can't use SAVEDESTRUCTOR_X to undo the damage. This commit leaves the 'PL_savestack_ix += 5', because in this case, with unsafe signals, it *is* possible to interrupt halfway through a new set of save data being pushed onto the stack, and it *is* possible for this to be undone via SAVEDESTRUCTOR_X. (But it's still unsafe and half-baked.) This fixes [perl #85206].
* Detect unsafe signals more reliably on BSD/SolarisLeon Timmermans2011-02-241-2/+2
| | | | | | | | | | | | | | | | Previous versions of the Posix spec allowed the struct siginfo_t* parameter passed to the signal handler to be NULL in certain cases. More recent Posix specifications (SUSv3) have rescinded this: Now this parameter is required always to be non-NULL. However we use this parameter to differentiate between safe and unsafe signals, as in the former it will always be NULL and in the latter case it should have been non-NULL. This patch fixes this issue by also relying on the ucontext_t* parameter. This should reliably be non-NULL when using unsafe signals handlers. Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
* No sip without SA_SIGINFO. Broken in c22d665.Craig A. Berry2011-02-171-1/+1
|
* Unblock signal-mask on error for unsafe signalsLeon Timmermans2011-02-171-2/+14
|
* multifile patch against blead/pod/*.podTom Christiansen2011-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | I mostly fixed spelling mistakes, some of very long standing, but a few files got more attentive word-smithying. I've updated: pod/perl.pod pod/perldelta.pod pod/perl592delta.pod pod/perl5120delta.pod pod/perl51310delta.pod pod/perl5139delta.pod pod/perlfunc.pod pod/perlop.pod pod/perlrebackslash.pod pod/perlrecharclass.pod pod/perlutil.pod pod/perlhack.pod pod/perlintern.pod pod/perlnetware.pod pod/perlpolicy.pod
* Also unblock signal handlers throwing an exceptionLeon Timmermans2011-01-181-12/+19
| | | | | Also handle and test the edge case of a signal handler throwing an exception
* Conditionally unblock after signal handler[#82040]Leon Timmermans2011-01-171-3/+20
| | | | | Only unblock signal after a safe-signal handler is executed if that signal was also unblocked before the handler.
* In Perl_write_to_stderr(), use Perl_magic_methcall() if STDERR is tied.Nicholas Clark2011-01-131-0/+11
| | | | | | Add a flag G_WRITING_TO_STDERR to signal that Perl_magic_methcall() needs to localise PL_stderrgv to NULL, and save/free temps, inside its ENTER/LEAVE pair.
* Better handling of magic methods freeing the SVDavid Mitchell2010-12-301-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for RT #81230 (and more). Currently, mg_get() works around the case where the called magic (e.g. FETCH) frees the magic SV. It does this by unconditionally pushing the SV on the tmps stack before invoking the method. There are two issues with this. Firstly, it may artificially extend the life of the SV. This was the root of the problem with #81230. There, the DB_File code, under -T, created a tainted tied object. Accessing the object (within FETCH as it happens), caused mg_get() to be invoked on the object (due to the taint magic), and thus extend the life of the object. This then caused c<untie %h if $h{k}> to give the warning untie attempted while 1 inner references still exist. This only became noticeable after efaf36747029c85b4d8825318cb4d485a0bb350e, which stopped wrapping magic method calls in SAVETMPS/FREETMPS. The second issue issue that this protection only applies to mg_get(); functions like mg_set() can still segfault if the SV is deleted. This commit fixes both problems as follows: First, the protection mechanism is moved out of mg_get() and into save_magic() / restore_magic(), so that it protects more things. Secondly, the protection is now: * in save_magic(), SvREFCNT_inc() the SV, thus protecting it from being freed during FETCH (or whatever) * in restore_magic(), SvREFCNT_dec() the SV, undoing the protection without extending the life of the SV, *except* if the refcount is 1 (ie FETCH tried to free it), then push it on the mortals stack to extend it life a bit so our callers wont choke on it.
* Remove lots of unused, VMS-specific variables.Craig A. Berry2010-12-021-1/+0
| | | | Brought to you by -Duser_c_flags=/WARN=(ENABLE=LEVEL5,INFORMATIONAL=ALL)
* Add mg_findextFlorian Ragwitz2010-11-301-9/+36
|
* Implement $^A taintingNiko Tyni2010-11-141-0/+10
| | | | | | | | | The format accumulator $^A now becomes tainted when formline() is called with tainted data. There is still one failing test from the TODO set; it seems that the $^A get magic is handled too late for the taintedness to show up.
* Eliminate PL_dirtyFlorian Ragwitz2010-11-141-1/+1
| | | | | It now only exists as a compatibility macro for extensions that want to introspect it.
* Add ${^GLOBAL_PHASE}Florian Ragwitz2010-11-141-1/+7
| | | | This exposes the current top-level interpreter phase to perl space.
* [perl #77238] Aliased @ISA does not workFather Chrysostomos2010-11-131-11/+17
| | | | | This makes aliased @ISA arrays work by storing a non-magical AV as the mg_obj if there need to be multiple entries.
* tidy code in Perl_sighandler()David Mitchell2010-11-011-14/+13
| | | | | | | | | | | | | | | | | | | 1) compress if (...) flag |= 1 ... if (flag & 1) { ... into if (...) { flag |= 1 .... 2) re-order the flag bits, since over the years some bits have become redundant.
* RT #76248: double-freed SV with nested sig-handlerDavid Mitchell2010-11-011-22/+21
| | | | | | | | | | | | | | | | | | | There was some buggy code in Perl_sighandler() related to getting an SV with the signal name to pass to the perl-level handler function. ` Basically: on threaded builds, a sig handler that died leaked PL_psig_name[sig]; on unthreaded builds, in a recursive handler that died, PL_sig_sv was prematurely freed. PL_sig_sv was originally just a file static var that was not recursion-save anyway, and got promoted to perlvars.h when it should instead have been done away with. So I've got rid of it now, and rationalised the code, which fixed the two issues listed above. Also added an assert which makes the dodgy manual popping of the save stack slightly less dodgy.
* Switch the core MRO code over to HvENAMEFather Chrysostomos2010-10-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | This has the side-effect of fixing these one-liners: $ perl5.13.5 -le' my $glob = \*foo::ISA; delete $::{"foo::"}; *$glob = *a' Bus error $ perl5.13.5 -le' my $glob = \*foo::ISA; delete $::{"foo::"}; *$glob = []' Bus error $ perl5.13.6 -le'sub baz; my $glob = \*foo::bar; delete $::{"foo::"}; *$glob = *baz;' Bus error $ perl5.13.6 -le'sub foo::bar; my $glob = \*foo::bar; delete $::{"foo::"}; *$glob = *baz;' Bus error In the first two cases the crash was inadvertently fixed (isn’t it nice when that happens?) in 5.13.6 (by 6f86b615fa7), but there was still a fatal error: Can't call mro_isa_changed_in() on anonymous symbol table at -e line 1. Because sv_clear calls ->DESTROY, if an object’s stash has been detached from the symbol table, mro_get_linear_isa can be called on a hash with no HvENAME. So HvNAME is used as a fallback for those cases.
View Lorry Controller Status