| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In restore_magic(), which is called after any magic processing, all of
the public OK flags have been shifted into the private OK flags. Thus
the lack of an appropriate public OK flags was used to trigger both get
magic and required conversions. This scheme did not cover ROK, however,
so all properly written code had to make sure mg_get was called the right
number of times anyway. Meanwhile the private OK flags gained a second
purpose of marking converted but non-authoritative values (e.g. the IV
conversion of an NV), and the inadequate flag shift mechanic broke this
in some cases.
This patch removes the shift mechanic for magic flags, thus exposing (and
fixing) some improper usage of magic SVs in which mg_get() was not called
correctly. It also has the side effect of making magic get functions
specifically set their SVs to undef if that is desired, as the new behavior
of empty get functions is to leave the value unchanged. This is a feature,
as now get magic that does not modify its value, e.g. tainting, does not
have to be special cased.
The changes to cpan/ here are only temporary, for development only, to
keep blead working until upstream applies them (or something like them).
Thanks to Rik and Father C for review input.
|
| |
|
|
| |
that was introduced by some guy named Chip in 1997 (e3c19b7bc9)
|
| | |
|
| |
|
|
|
| |
since signals can arrive at any point, clearing $@ isn't a safe
thing to do
|
| | |
|
| |
|
|
| |
This fixes RT #75596.
|
| |
|
|
| |
I’m running out of synonyms for ‘remove’.
|
| |
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
| |
|
|
|
| |
C++ requires #include directives to be at file scope, but we've
been lazy and haven't been doing that.
|
| |
|
|
| |
Now that ‘A’ magic is gone, nothing is using this function.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
$^N is a magical variable, like $1 and $2, with the usual ‘sv’
magic. So it is handled by Perl_magic_get and Perl_magic_set. But
Perl_magic_set didn’t have a case for it, so it simply ignored it and
did nothing, like a tied variable with an empty STORE method.
Now assigning to $^N has the same affect as assigned to the numbered
variable to which it corresponds. If there is no corresponding cap-
ture from the last match, or in the absence of regexp plugins, it
croaks with ‘Modification of a read-only value’.
|
| |
|
|
|
| |
Otherwise cv_set_call_checker has no effect inside an attribute han-
dler for a closure.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Magic attached to hash elements has its key stored differently depend-
ing on how it was supplied to hv_common. hv_store passes a string/
length pair to hv_common, while hv_store_ent passes an SV.
magic_clearhint wasn’t able to handle string/length pairs, and only
worked with SVs, resulting in assertion failures or crashes.
This commit fixes magic_clearhint, so that XS code can use hv_store on
hint hashes.
|
| | |
|
| |
|
|
|
|
| |
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].
|
| |
|
|
| |
Which broke the build on both VMS and Win32.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
If we are going to skip all set-magic when restoring a localised tied
$_, there’s no point in looping through it.
|
| |
|
|
|
| |
This commit finishes the work of 658a9f3 by skipping FETCH as well as
STORE during local($_).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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;
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This adds _pv, _pvn, and _pv versions of whichsig() in mg.c, which
get both kill "NAME" and %SIG lookup nul-clean.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
$[ 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Store the target SV in mg_obj, instead of LvTARG(). This slightly reduces both
code complexity and runtime memory use.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Use this to replace S_is_container_magic() in mg.c with a direct lookup.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
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 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 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].
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| | |
|
