| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The debugger implements breakpoints by setting/clearing OPf_SPECIAL on
OP_DBSTATE ops. This means that it is writing to the optree at runtime,
and it falls foul of the enforced read-only OP slabs when debugging with
-DPERL_DEBUG_READONLY_OPS
Avoid this by removing static from Slab_to_rw(), and using it and Slab_to_ro()
in Perl_magic_setdbline() to temporarily make the slab re-write whilst
changing the breakpoint flag.
With this all tests pass with -DPERL_DEBUG_READONLY_OPS (on this system)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
If a scalar is gmagical, then the string buffer could change without
the utf8 pos cache being updated.
So it should respond to get-magic, not just set-magic. Actually add-
ing get-magic to the utf8 magic vtable would cause all scalars with
this magic to be flagged gmagical. Instead, in magic_get, we can call
magic_setutf8.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most register declarations in C code (and accompanying
documentation) in the Perl core. Retained are those in the ext
directory, Configure, and those that are associated with assembly
language.
See:
http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c
which says, in part:
There is no good example of register usage when using modern compilers
(read: last 10+ years) because it almost never does any good and can do
some bad. When you use register, you are telling the compiler "I know
how to optimize my code better than you do" which is almost never the
case. One of three things can happen when you use register:
The compiler ignores it, this is most likely. In this case the only
harm is that you cannot take the address of the variable in the
code.
The compiler honors your request and as a result the code runs slower.
The compiler honors your request and the code runs faster, this is the least likely scenario.
Even if one compiler produces better code when you use register, there
is no reason to believe another will do the same. If you have some
critical code that the compiler is not optimizing well enough your best
bet is probably to use assembler for that part anyway but of course do
the appropriate profiling to verify the generated code is really a
problem first.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These are only used for storing a string and an IV.
Making them into full-blown SVt_PVFMs is overkill.
FmLINES was only being used on these three scalars. So make it use
the SvIVX field. struct xpvfm no longer needs an xfm_lines member,
because SVt_PVFMs no longer use it.
This also causes a TODO test in taint.t to start passing, but I do
not fully understand why. But at least that’s progress. :-)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A substitution forces its target to a string upon successful substitu-
tion, even if the substitution did nothing:
$ ./perl -Ilib -le '$a = *f; $a =~ s/f/f/; print ref \$a'
SCALAR
Notice that $a is no longer a glob after s///.
But vstrings are different:
$ ./perl -Ilib -le '$a = v102; $a =~ s/f/f/; print ref \$a'
VSTRING
I fixed this in 5.16 (1e6bda93) for those cases where the vstring ends
up with a value that doesn’t correspond to the actual string:
$ ./perl -Ilib -le '$a = v102; $a =~ s/f/o/; print ref \$a'
SCALAR
It works through vstring set-magic, that does the check and removes
the magic if it doesn’t match.
I did it that way because I couldn’t think of any other way to fix
bug #29070, and I didn’t realise at the time that I hadn’t fixed
all the bugs.
By making SvTHINKFIRST true on a vstring, we force it through
sv_force_normal before any in-place string operations. We can also
make sv_force_normal handle vstrings as well. This fixes all the lin-
gering-vstring-magic bugs in just two lines, making the vstring set-
magic (which is also slow) redundant. It also allows the special case
in sv_setsv_flags to be removed.
Or at least that was what I had hoped.
It turns out that pp_subst, twists and turns in tortuous ways, and
needs special treatment for things like this.
And do_trans functions wasn’t checking SvTHINKFIRST when arguably it
should have.
I tweaked sv_2pv{utf8,byte} to avoid copying magic variables that do
not need copying.
|
| |
|
|
|
| |
(turning off other OK flags), make them byte strings; if wide characters can't
be downgraded to bytes, leave the string utf8 and issue a warning.
|
| |
|
|
| |
These were missed in commit 1203306491d341ed, which renamed ptr to key.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
