summaryrefslogtreecommitdiff
path: root/mg.c
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* List assignment to package scalar refFather Chrysostomos2014-10-101-1/+8
| | | | | | | | | | \ on the lhs returns a special magical scalar with set-magic that does the aliasing. I considered having a separate abind op that would be like aassign, but different. However, I realised that for ($x, \$y) = ... to work it would have to duplicate all of aassign. So I went with the sim- pler magic implementation.
* Add lvref magic typeFather Chrysostomos2014-10-101-0/+8
| | | | | I just couldn’t resist using the backslash for the character, even though I had to tweak mg_vtable.pl to make it work.
* [perl #122445] use magic on $DB::single etc to avoid overload issuesTony Cook2014-10-091-0/+21
| | | | | | | | | This prevents perl recursing infinitely when an overloaded object is assigned to $DB::single, $DB::trace or $DB::signal This is done by referencing their values as IVs instead of as SVs in dbstate, and by adding magic to those variables so that assignments to the scalars update the PL_DBcontrol array.
* Implement the bipolar read-only systemFather Chrysostomos2014-09-201-12/+11
| | | | | | | | | | | | | | | | | | | | | This fixes bugs related to Hash::Util::unlock accidentally unlocking internal scalars (e.g., that returned by undef()) and allowing them to be modified. Internal read-only values are now marked by two flags, the regular read-only flag, and the new ‘protected’ flag. Before this SvREADONLY served two purposes: 1) The code would use it to protect things that must not be modi- fied, ever (except when the core sees fit to do so). 2) Hash::Util and everybody else would use it to make this unmodifia- ble temporarily when requested by the user. Internals::SvREADONLY serves the latter purpose and only flips the read-only flag, so things that need to stay read-only will remain so, because of the ‘other’ read-only flag, that CPAN doesn’t know about. (If you are a CPAN author, do not read this.)
* mg.c: Avoid reifying GV for undefined sig handlerFather Chrysostomos2014-09-151-1/+3
|
* Make ‘SIG handler not defined’ UTF8- and null-safeFather Chrysostomos2014-09-151-5/+11
|
* Don’t call save_re_contextFather Chrysostomos2014-09-121-1/+0
| | | | It is an empty function.
* [perl #122669] Don’t taint at compile timeFather Chrysostomos2014-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | #!perl -T # tainted constant use constant K=>$^X; # Just reading the constant for the sake of folding can enabled # taintedness at compile time. 0 if K; # Taintedness is still on when the ‘strict.pm’ SV is created, so # require croaks on it (‘Insecure dependency’). use strict; The fix is simply not to propagate taintedness at compile time. Hence, the value of K will still be tainted at run time (require(K) croaks), but just reading the value of K at compile time won’t taint subsequent string literals (or barewords treated as strings). ‘Compile time’ here is relative: Taintedness still wafts about as usual when BEGIN blocks are executed, because code is actually run- ning. It’s when code is being parsed that propagation is disabled. The reason taint propagation could span across statements at compile time was that *execution* of a new statement resets taintedness, whereas parsing is oblivious to it.
* Atol can be strtol in disguise, so grok_atou.Jarkko Hietaniemi2014-07-221-5/+7
|
* Remove or downgrade unnecessary dVAR.Jarkko Hietaniemi2014-06-251-47/+2
| | | | | | | | You need to configure with g++ *and* -Accflags=-DPERL_GLOBAL_STRUCT or -Accflags=-DPERL_GLOBAL_STRUCT_PRIVATE to see any difference. (g++ does not do the "post-annotation" form of "unused".) The version code has some of these issues, reported upstream.
* PERL_UNUSED_CONTEXT -> remove interp context where possibleDaniel Dragan2014-06-241-12/+7
| | | | | | | | | | | | | | | | | | | | | Removing context params will save machine code in the callers of these functions, and 1 ptr of stack space. Some of these funcs are heavily used as mg_find*. The contexts can always be readded in the future the same way they were removed. This patch inspired by commit dc3bf40570. Also remove PERL_UNUSED_CONTEXT when its not needed. See removal candidate rejection rational in [perl #122106]. -Perl_hv_backreferences_p uses context in S_hv_auxinit commit 96a5add60f was wrong -Perl_whichsig_sv and Perl_whichsig_pv wrongly used PERL_UNUSED_CONTEXT from inception in commit 84c7b88cca -in authors opinion cast_* shouldn't be public API, no CPAN grep usage, can't be static and/or inline optimized since it is exported -Perl_my_unexec move to block where it is needed, make Win32 block, context free, for inlining likelyhood, private api and only 2 callers in core -Perl_my_dirfd make all blocks context free, then change proto -Perl_bytes_cmp_utf8 wrongly used PERL_UNUSED_CONTEXT from inception in commit fed3ba5d6b
* Revert "/* NOTREACHED */ belongs *before* the unreachable."Jarkko Hietaniemi2014-06-191-2/+1
| | | | | | This reverts commit 148f39b7de6eae9ddd59e0b0aff691d6abea7aca. (Still needs more work, but wanted to see how well this passed with Jenkins.)
* /* NOTREACHED */ belongs *before* the unreachable.Jarkko Hietaniemi2014-06-191-1/+2
| | | | | | Definitely not *after* it. It marks the start of the unreachable, not the first unrechable line. And if they are in that order, it looks better to linebreak after the lint hint.
* With this we are g++ -Wunused-* clean.Jarkko Hietaniemi2014-06-181-0/+6
|
* Some low-hanging -Wunreachable-code fruits.Jarkko Hietaniemi2014-06-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | - after return/croak/die/exit, return/break are pointless (break is not a terminator/separator, it's a goto) - after goto, another goto (!) is pointless - in some cases (usually function ends) introduce explicit NOT_REACHED to make the noreturn nature clearer (do not do this everywhere, though, since that would mean adding NOT_REACHED after every croak) - for the added NOT_REACHED also add /* NOTREACHED */ since NOT_REACHED is for gcc (and VC), while the comment is for linters - declaring variables in switch blocks is just too fragile: it kind of works for narrowing the scope (which is nice), but breaks the moment there are initializations for the variables (the initializations will be skipped since the flow will bypass the start of the block); in some easy cases simply hoist the declarations out of the block and move them earlier Note 1: Since after this patch the core is not yet -Wunreachable-code clean, not enabling that via cflags.SH, one needs to -Accflags=... it. Note 2: At least with the older gcc 4.4.7 there are far too many "unreachable code" warnings, which seem to go away with gcc 4.8, maybe better flow control analysis. Therefore, the warning should eventually be enabled only for modernish gccs (what about clang and Intel cc?)
* Revert "Some low-hanging -Wunreachable-code fruits."Jarkko Hietaniemi2014-06-131-2/+2
| | | | | | | This reverts commit 8c2b19724d117cecfa186d044abdbf766372c679. I don't understand - smoke-me came back happy with three separate reports... oh well, some other time.
* Some low-hanging -Wunreachable-code fruits.Jarkko Hietaniemi2014-06-131-2/+2
| | | | | | | | | | | | | | | | | | - after croak/die/exit (or return), break (or return!) are pointless (break is not a terminator/separator, it's a promise of a jump) - after goto, another goto (!) is pointless - in some cases (usually function ends) introduce explicit NOT_REACHED to make the noreturn nature clearer (do not do this everywhere, though, since that would mean adding NOT_REACHED after every croak) - for the added NOT_REACHED also add /* NOTREACHED */ since NOT_REACHED is for gcc (and VC), while the comment is for linters - declaring variables in switch blocks is just too fragile: it kind of works for narrowing the scope (which is nice), but breaks the moment there are initializations for the variables (they will be skipped!); in some easy cases simply hoist the declarations out of the block and move them earlier There are still a few places left.
* Silence several -Wunused-parameter warnings about my_perlBrian Fraser2014-06-131-0/+3
| | | | | | | | This meant sprinkling some PERL_UNUSED_CONTEXT invocations, as well as stopping some functions from getting my_perl in the first place; all of the functions in the latter category are internal (S_ prefix and s or i in embed.fnc), so this should be both safe and economical.
* perlapi: Include general informationKarl Williamson2014-06-051-1/+2
| | | | | | | | | | | Unlike other pod handling routines, autodoc requires the line following an =head1 to be non-empty for its text to be included in the paragraph started by the heading. If you fail to do this, silently the text will be omitted from perlapi. I went through the source code, and where it was apparent that the text was supposed to be in perlapi, deleted the empty line so it would be, with some revisions to make more sense. I added =cuts where I thought it best for the text to not be included.
* Revert "PATCH: [perl #119499] "$!" with UTF-8 flag"Karl Williamson2014-06-051-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit b17e32ea3ba5ef7362d2a3d1a433661afb897786. With this commit, the stringification of $! will have the UTF-8 flag set when the text is actually non-ASCII UTF-8. The reverted commit itself reverted code that was to fix bugs with this discrepancy of the UTF-8 flag, but which caused backward-compatibility problems with existing code. Several things have happened in the interim which allows us to experimentally resotre the previously reverted changes. One is that this is early in the 5.21 cycle, and we have plenty of time to see what negative consequences this may cause. Two is that the returned text will only be in UTF-8 if the stringification happens within the scope of 'use locale'. This means that the negative effects won't happen for code, like ack, that is otherwise locale unaware. Third, the 'locale' pragma has been enhanced to allow the program to only have locale awareness of LC_MESSAGES. Code that needs to continue the 5.20 and earlier behavior can do the stringification within the scopes of both 'use bytes' and 'use locale ":messages". No other Perl operations will be affected by locale; only $! and $^E stringification. The 'bytes' pragma causes the UTF-8 flag to not be set, just as in previous Perl releases.
* Use C locale for "$!" ouside 'use locale' scopeKarl Williamson2014-06-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The stringification of $! has long been an outlier in Perl locale handling. The theory has been that these operating system messages are likely to be of use to the final user, and should be in their language. Things like No space left on device Can't fork are not something the program is likely to handle, but could be meaningfully helpful to the end-user. There are problems with this though. One is that many perl messages are in English, with the $! appended to them, so that the resultant message is of mixed language, and may need to be translated anyway. Things like No space left on device probably won't need the remaining portion of the message to give someone a clear indication as to what's wrong. But there are many other messages where both the OS error and the Perl error would be needed togther to understand the problem. An on-line translation tool can be used to do this. Another problem is that it can lead to garbage coming out on the user's terminal when the program is not expecting UTF-8, but the underlying locale is UTF-8. This is what happens in Bug #112208, and another that was merged with it. It's a lot harder to translate mojibake via an online tool than English. This commit solves that by using the C locale for messages, except within the scope of 'use locale'. It is extremely likely that the messages in the C locale will be English, but if not they will be ASCII, and there will be no garbage printed. A program that says "use locale" is indicating that it has the intelligence necessary to deal with locales.
* Use PERL_UNUSED_RESULT.Jarkko Hietaniemi2014-06-021-30/+22
| | | | | | | (1) Enhance its description. (2) Simplify it: define only if has warn_unused_result. (3) Make it use STMT_START { ... } STMT_END to be less GNU-extensiony. (4) Redo 04783dc7 ("fix 'ignoring return value' compiler warnings") with it.
View Lorry Controller Status