summaryrefslogtreecommitdiff
path: root/mg.c
Commit message (Collapse)AuthorAgeFilesLines
* new feature @{^CAPTURE} (and %{^CAPTURE} and %{^CAPTURE_ALL})Yves Orton2016-11-011-12/+25
| | | | | | | | | @{^CAPTURE} exposes the capture buffers of the last match as an array. So $1 is ${^CAPTURE}[0]. %{^CAPTURE} is the equivalent to %+ (ie named captures) %{^CAPTURE_ALL} is the equivalent to %- (ie all named captures).
* mg.c: use new SvPVCLEAR and constant string friendly macrosYves Orton2016-10-191-6/+6
|
* add some code comments for the users of delimcpy()David Mitchell2016-09-071-0/+2
| | | | | | | | While fixing delimcpy(), I found that it wasn't always clear what its callers did, so I've added some extra code comments. also add a balancing '}' in a comment block to help editors that jump between matching brackets.
* Tainted dirs on VMS when not under DCL.Craig A. Berry2016-09-051-4/+7
| | | | | | | Since 483efd0abe3 the path delimiter is a ':' instead of '|' on VMS when running under a Unix shell. So use that as a guide to whether we should use a colon or a slash to detect relative directories that should be tainted.
* Fix checks for tainted dir in $ENV{PATH}Father Chrysostomos2016-09-031-1/+1
| | | | | | | | | | | | | | | | | | | $ cat > foo #!/usr/bin/perl print "What?!\n" ^D $ chmod +x foo $ ./perl -Ilib -Te '$ENV{PATH}="."; exec "foo"' Insecure directory in $ENV{PATH} while running with -T switch at -e line 1. That is what I expect to see. But: $ ./perl -Ilib -Te '$ENV{PATH}="/\\:."; exec "foo"' What?! Perl is allowing the \ to escape the :, but the \ is not treated as an escape by the system, allowing a relative path in PATH to be consid- ered safe.
* Use new name 'is_utf8_invariant_string' in coreKarl Williamson2016-08-311-1/+1
| | | | | | This changes the places in the core to use the clearer synonym added by the previous commit. It also changes one place that hand-rolled its own code to use this function instead.
* Remove mg.c:_get_encodingFather Chrysostomos2016-07-131-6/+0
| | | | Nothing uses it now, and it does nothing.
* Remove PL_(lex_)encoding and all dependent codeFather Chrysostomos2016-07-131-34/+0
|
* Disable ${^ENCODING}Father Chrysostomos2016-07-131-34/+2
| | | | ${^ENCODING} is disabled and tests are modified to account.
* mg.c: move declaration of i closer to its useLukas Mai2016-01-311-1/+1
| | | | | This should avoid the "unused variable 'i'" warning that pops up in some configurations.
* Probe for and expose more fields for SA_SIGINFODagfinn Ilmari Mannsåker2016-01-261-7/+21
| | | | | | | | These are all specified by POSIX/SUSv3, but not all platforms have them, as mentioned in POSIX.pm. We can only test the pid, uid and code fields, since they are the only ones that are defined for a user-sent signal.
* Perl_magic_set(): remove unused var 's'David Mitchell2015-12-011-7/+8
| | | | | | | | This var is (mostly) unused, but is set in a couple of places, hence: mg.c:2657:17: warning: variable ‘s’ set but not used In the one place it is used, declare it in a narrower scope.
* split off the $0 setting so mutex use can be annotatedJarkko Hietaniemi2015-11-231-68/+81
| | | | | | No warnings were emitted since the use of the PL_dollarzero_mutex was correctly bracketed by mutex lock and unlock, but by splitting off the code and annotating it is more likely to stay correct.
* reimplement $^WIN32_SLOPPY_STAT as a magic varDaniel Dragan2015-10-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original implementation in commit cba61fe146 was sloppy. It is named like a special var, it is listed as a special var, but it was a regular GV. Since nobody knows this var exists, and full stat is the default (which I disagree with see below). There will be alot more PP and C/XS perl stat() calls (atleast a couple to dozens or low 100s for short lived perl processes) than reads/writes to this global scalar (rounded to 0 R/Ws) in a Win32 perl process. So avoid the 1 usually failing GV package (hash) lookup for each PP/XS/PL C stat by using magic vars and a C bool. This is a perf increase. Use sv_true instead of SvTRUE_NN because this code is extremely rare to execute and the macro has large machine code. I disagree with the default being full stat with since this increases the number of kernel IO calls and ASCII->UTF16 conversions, and there was perf criticism in the original thread that implemented this this http://www.nntp.perl.org/group/perl.perl5.porters/2006/02/msg109917.html but why full stat is default is for another ticket. This patch lessens the overhead of full stat until something else is decided. Change the initial value of the sloppystat setting for miniperl to be true instead of doing it in buildcustomize.pl in PP. Revert part of commit 8ce7a7e8b0 "speed up miniperl require on Win32" to acomplish this. Unlike Unix perl, no object files are shared between mini and full perl, so changing the default is fine on Win32 Perl. If minitest/miniperl really need hard link testing/support, they can explictly turn off sloppy stat and enable full stat with the special var. Changing the stat default from C for miniperl avoids creating the special GV on each miniperl process start as it previously was with the buildcustomize.pl way. Changing stat setting in C and not PP also saves a couple IO calls in win32_stat when opening the first .pl if it isn't -e, and opening buildcustomize.pl in all permutations. The PP code in S_parse_body contains a -f. See ticket for this patch for details. Only CPAN use of this special var is File-Stat-Moose-0.06/lib/File/Stat/Moose.pm#L208 according to cpangrep.
* fix up EXTEND() callersDavid Mitchell2015-10-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | The previous commit made it clear that the N argument to EXTEND() is supposed to be signed, in particular SSize_t, and now typically triggers compiler warnings where this isn't the case. This commit fixes the various places in core that passed the wrong sort of N to EXTEND(). The fixes are in three broad categories. First, where sensible, I've changed the relevant var to be SSize_t. Second, where its expected that N could never be large enough to wrap, I've just added an assert and a cast. Finally, I've added extra code to detect whether the cast could wrap/truncate, and if so set N to -1, which will trigger a panic in stack_grow(). This also fixes [perl #125937] 'x' operator on list causes segfault with possible stack corruption
* amigaos4: setenv magic should work with __amigaos4__Andy Broad2015-09-051-2/+2
| | | | The code was protected with AMIGAOS which was AmigaOS 3.
* perlapi: Change some 'eg' to 'e.g.'Karl Williamson2015-09-031-2/+2
| | | | To make more standard
* perlapi: Add some S<>Karl Williamson2015-09-031-1/+1
| | | | | so that these constructs appear on a single output line for reader convenience.
* Various pods: Add C<> around many typed-as-is thingsKarl Williamson2015-09-031-13/+13
| | | | Removes 'the' in front of parameter names in some instances.
* perlapi, perlintern: Add L<> links to podKarl Williamson2015-09-031-8/+8
|
* perlapi: Use C<> instead of I<> for parameter names, etcKarl Williamson2015-08-011-1/+1
| | | | | The majority of perlapi uses C<> to specify these things, but a few things used I<> instead. Standardize to C<>.
* Remove PERL_OLD_COPY_ON_WRITEFather Chrysostomos2015-06-291-6/+0
|
* silence some gcc -pendantic warningsDavid Mitchell2015-06-191-1/+1
|
* Revert "Don’t call save_re_context"David Mitchell2015-03-301-0/+1
| | | | | | This reverts commit d28a9254e445aee7212523d9a7ff62ae0a743fec. Turns out we need save_re_context() after all
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | An empty cpan/.dir-locals.el stops Emacs using the core defaults for code imported from CPAN. Committer's work: To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed to be incremented in many files, including throughout dist/PathTools. perldelta entry for module updates. Add two Emacs control files to MANIFEST; re-sort MANIFEST. For: RT #124119.
* mg.c:Perl_magic_set: don't use 0 as "failed" gid_tHugo van der Sanden2015-03-101-2/+8
| | | | | | | | For [perl #123814] we added checking for grok_* parse failures in magic_set for $), but used 0 as the placeholder result in those cases (since we don't have an effective way to report an error for this). (Gid_t)(-1) is a safer placeholder, since on many systems that'll map to an explicit bad group id.
* [perl #123814] replace grok_atou with grok_atoUVHugo van der Sanden2015-03-091-2/+13
| | | | | | | | | | | | Some questions and loose ends: XXX gv.c:S_gv_magicalize - why are we using SSize_t for paren? XXX mg.c:Perl_magic_set - need appopriate error handling for $) XXX regcomp.c:S_reg - need to check if we do the right thing if parno was not grokked Perl_get_debug_opts should probably return something unsigned; not sure if that's something we can change.
* Remove get-magic from $/Father Chrysostomos2015-02-081-2/+1
| | | | | | | | | | | | | | | and use a different approach to prevent $/ from being set to a bad value. This should fix ticket #123739. Commit v5.21.8-197-g5fe499a made $/’s get-magic read PL_rs, so that the croak when setting $/ to a bad value would not leave $/ with that bad value, in order to fix bug #123218. Some CPAN modules do not like $/ reading PL_rs that way. So we have to change this back. I am not actually removing the get- magic, but just making it a no-op, as it was before. The set- magic now sets $/ back to its previous value before croaking.
* [perl #123218] "preserve" $/ if set to a bad valueTony Cook2015-02-041-0/+1
| | | | and base/rs.t tests $/ not $!
* Revert the support for new warning categories outside of "all"Ævar Arnfjörð Bjarmason2015-01-251-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | This reverts & amends my v5.21.7-151-gea5519d and Karl Williamson's v5.21.7-183-g2f3cbe1, the latter was only need because of the former. I've also taken the opportunity to fix the long-standing trivial bug with misaligned code in warnings.{pm,h}. That was easier to commit along with this than to split it up from the other generated changes. Why revert this? See the "use warnings 'absolutely-all-almost';" thread on perl5-porters for the latest summary: http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225066.html Basically as I explained in v5.21.7-151-gea5519d the current design of the API makes it too contentious to freely add new warnings, but there's no consensus on how to solve that. I.e. whether we should just add them to "all", or do this change, or several other possible things outlined in that thread and elsewhere. Since the deadline for contentious changes for v5.22 is already past us I'm backing this out for now.
* avoid C labels in column 0David Mitchell2015-01-211-1/+1
| | | | | | | | | Generally the guideline is to outdent C labels (e.g. 'foo:') 2 columns from the surrounding code. If the label starts at column zero, then it means that diffs, such as those generated by git, display the label rather than the function name at the head of a diff block: which makes diffs harder to peruse.
* Add support for new warning categories outside of "all"Ævar Arnfjörð Bjarmason2014-12-291-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When someone suggests a new warning on p5p it always often up being argued about on the basis that it'll break existing code, and that we shouldn't add warnings for possibly legitimate code just because it's unusual or odd. As I pointed out in a discussion about RT #121025 (see [1]) we only keep having this discussion because until now we've had no facility to add new warnings outside of the default set that'll be retroactively enabled for everything that does 'use warnings'. This patch introduces such a facility. As a proof of concept I'm adding a warning for something that was added as a warning in the past, but pulled out because it was deemed too controversial at the time: warning about the use of grep in void context. That warning was added back in v5.10.0-218-g74295f0 but quickly pulled out in v5.10.0-230-gf5df478. See [2] for the discussion about it at the time. Now if you do: use warnings; grep /42/, (1,2); You'll get no warnings as before, but if you do: use warnings qw(extra); # Or its sole subcategory: void_unusual grep /42/, (1,2); You'll get a warning about "Unusual use of grep in void context". To turn off this warning once you've turned it on it's *not* sufficient to do: no warnings; You need to do: no warnings qw(pedantic); Or: no warnings qw(everything); I'm willing to change that, but first we should ask ourselves whether this should continue to remain a symmetric operation: {use,no} warnings ['all']; There's more elaboration on how this works in the changes I'm making to the perldelta and the warnings documentation. But briefly this should be 100% backwards compatible, but allow us to have our cake and eat it too in the future by adding new warnings without imposing them on existing code written against older perl versions (unless that code explicitly requested to get new warnings as they upgrade perl). The patch to the warnings.pm documentation lays out a backwards compatibility policy for warnings, we promise that we'll continue the status quo with the "all" category, but for other categories (including future additions) we'll make such promises on a per-category basis. TODO: I wanted to come up with some more general facility for being able to add these new warnings without altering the behavior of the -w and -W switches. I.e. now we'll emit this, as intended: $ ./perl -Ilib -w -e 'grep /42/, (1,2)' $ ./perl -Ilib -W -e 'grep /42/, (1,2)' $ ./perl -Ilib -e 'use warnings; grep /42/, (1,2)' $ ./perl -Ilib -e 'use warnings "extra"; grep /42/, (1,2)' Unusual use of grep in void context at -e line 1. I.e. we don't want -w and -W to mean "use warnings 'everything'", it should continue to mean "use warnings 'all'". But due to how they're implemented I couldn't find an easy way to generalize this. Right now I'm just hardcoding an exception to the new warning category I've added outside "all" for these warnings. That should be followed-up with a more general solution, but for now if we only have a few of these catogeries we should be fine. This patch incorporates work from Andreas Guðmundsson <andreasg@nasarde.org> who picked up an earlier version of mine and figured out the change being made to mg.c here. That change removes an optimization in the ${^WARNING_BITS} magic which might make things a tad slower. 1. https://rt.perl.org/Ticket/Display.html?id=121025#txn-1276663 2. http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131922.html
* Fix compilation errors in mg.c with MinGW/gcc -xc++Steve Hay2014-12-241-0/+2
| | | | | error: 'sip' was not declared in this scope error: 'uap' was not declared in this scope
* Make PADNAMELIST a separate typeFather Chrysostomos2014-11-301-2/+0
| | | | This is in preparation for making PADNAME a separate type.
* hv_store_ent() return value unused.Jarkko Hietaniemi2014-11-271-2/+2
| | | | | | | mg.c: In function 'Perl_magic_setlvref': mg.c:2549:2: warning: value computed is not used [-Wunused-value] pp.c: In function 'Perl_pp_refassign': pp.c:6263:2: warning: value computed is not used [-Wunused-value]
* Change core to use is_invariant_string()Karl Williamson2014-11-261-8/+9
| | | | | is_ascii_string's name has misled me in the past; the new name is clearer.
* Protect ${^E_NCODING} from abuseFather Chrysostomos2014-11-221-0/+4
| | | | | | When read, it is now always undef. When set, it croaks as though read-only except in the encoding package. Hopefully that will dis- suade anyone from depending on it.
* mg.c: Remove poorly considered assertionKarl Williamson2014-11-211-3/+0
| | | | | | | | See http://nntp.perl.org/group/perl.perl5.porters/222464 and following. The final resolution of what to do here hasn't been made, but the assertion is definitely not the way to go.
* mg.c: _get_encoding needs dVARFather Chrysostomos2014-11-201-0/+1
|
* Deprecate setting ${^ENCODING}Dagfinn Ilmari Mannsåker2014-11-201-0/+4
| | | | | The commiter added a no warnings in t/op/leaky-magic.t, and made other minor changes because of rebasing issues.
* mg.c: White-space onlyKarl Williamson2014-11-201-8/+8
| | | | Indent due to new blocks from previous commit
* Make encoding pragma lexical in scopeKarl Williamson2014-11-201-4/+60
| | | | | | | | | | | | | | | | | | | | The encoding pragma is deprecated, but in the meantime it causes spooky action at a distance with other modules that it may be combined with. In these modules, operations such as chr(), ord(), and utf8::upgrade() will suddenly start doing the wrong thing. The documentation for 'encoding' has said to call it after loading other modules, but this may be impractical. This is especially bad with anything that auto-loads at first use, like \N{} does now for charnames. There is an issue with combining this with setting the variable ${^ENCODING} directly. The potential for conflicts has always been there, and remains. This commit introduces a shadow hidden variable, subservient to ${^ENCODING} (to preserve backwards compatibility) that has lexical scope validity. The pod for 'encoding' has been revamped to be more concise, clear, use more idiomatic English, and to speak from a modern perspective.
* Make a function to get PL_encoding's valueKarl Williamson2014-11-201-1/+9
| | | | | | This is in preparation for making the retrieval more complex in future commits than it is now. This is going into mg.c because the value is magical.
* Make $/=-1 warning default like other dep warningsFather Chrysostomos2014-11-141-1/+1
|
* fix some recent compiler warningsDavid Mitchell2014-10-171-2/+8
| | | | | | | | | | | Currently DBVARMG_SINGLE is deffed to 0, so mg->mg_private >= DBVARMG_SINGLE gives an 'always true' warning. sv_magicext's last arg is supposed to to be I32, but ARGTARG is a U32 or U64.
* foreach \$varFather Chrysostomos2014-10-111-1/+8
| | | | Some passing tests are still marked to-do. We need more tests still.
* List assignment to array and hash refsFather Chrysostomos2014-10-111-2/+20
| | | | | (\@a,\%h)=... works, but \(@a) and \(%h) do not. \(%h) correctly croaks. (\local @a, \local %h)=... also works.
* Assignment to hash element refsFather Chrysostomos2014-10-101-0/+4
|
* Assignment to array elem refsFather Chrysostomos2014-10-101-0/+4
|
* List assignment to lexical scalar refsFather Chrysostomos2014-10-101-3/+12
| | | | \($x,$y)=... does not work yet, but \(my $x) and (\$x, \$y) do.
View Lorry Controller Status