summaryrefslogtreecommitdiff
path: root/mg.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove DOS/DJGPP supportDagfinn Ilmari Mannsåker2021-11-021-2/+2
| | | | | | DJGPP is a port of the GNU toolchain to 32-bit x86 systems running DOS. The last known attempt to build Perl on it was on 5.20, which only got as far as building miniperl.
* gh19081: also deliver SIGFPE in an "unsafe" mannerHugo van der Sanden2021-09-081-0/+3
| | | | Bring it in line with the other "fault"-like signals SEGV, ILL and BUS.
* Convert some existing uses of SvRV_set() to use the new sv_setrv* family of ↵Paul "LeoNerd" Evans2021-08-251-5/+1
| | | | functions
* Only set IOKp, not IOK on $) and $(.Felipe Gasper2021-07-061-1/+7
| | | | | | | Issue #18955: This will prevent serializers from serializing these variables as numbers (which loses the additional groups). This restores behaviour from 5.16.
* Call magic on all elements on %SIG delocalizationLeon Timmermans2021-06-021-0/+18
|
* Set %ENV keys using the same byte-string logic as setting %ENV values.Felipe Gasper2021-04-161-1/+16
| | | | | | | | | | | | | Issue #18636: This extends the work from 613c63b465f01af4e535fdc6c1c17e7470be5aad to %ENV keys. Previously if you assigned an upgraded string as a key in %ENV, the string’s internal PV representation was sent to the OS. Now the string is “soft downgraded” before being given to the OS; if the downgrade fails--i.e., if the string contains code points above 255--then a warning is printed, and the string’s utf8 is assigned to the environment, as happens with %ENV values. A new internal macro, MgSV, is created to facilitate this work.
* mg.c: Silence compiler warningKarl Williamson2021-03-181-1/+1
| | | | | | This was generating warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
* fixup Perl_magic_freemglob()David Mitchell2021-02-221-4/+3
| | | | | | | | | | | | | In v5.33.3-24-g02a48966c3 I added the Perl_magic_freemglob() function, which allowed special-case handling of the pos() magic type to be removed from S_mg_free_struct(). However, I got it wrong, by more or less copying the same code from another such function I had just created. So I made Perl_magic_freemglob() free mg_ptr(), but in the case of pos magic, this doesn't point to a buffer which needs freeing. In fact its currently always NULL so attempting to free it is harmless - but this commit removes the free() for logical soundness and future robustness.
* style: Detabify indentation of the C code maintained by the core.Michael G. Schwern2021-01-171-1160/+1160
| | | | | | | | | | | This just detabifies to get rid of the mixed tab/space indentation. Applying consistent indentation and dealing with other tabs are another issue. Done with `expand -i`. * vutil.* left alone, it's part of version. * Left regen managed files alone for now.
* Remove empty "#ifdef"sTom Hukins2020-12-081-4/+0
|
* remove ${^WIN32_SLOPPY_STAT}Tony Cook2020-12-011-10/+0
| | | | | The new implementation, like the UCRT implementation, always opens the specified file.
* autodoc.pl: Enhance apidoc_section featureKarl Williamson2020-11-061-4/+4
| | | | | | | | | | | This feature allows documentation destined for perlapi or perlintern to be split into sections of related functions, no matter where the documentation source is. Prior to this commit the line had to contain the exact text of the title of the section. Now it can be a $variable name that autodoc.pl expands to the title. It still has to be an exact match for the variable in autodoc, but now, the expanded text can be changed in autodoc alone, without other files needing to be updated at the same time.
* remove assertion that collation magic has dataTony Cook2020-10-291-3/+6
| | | | | | | | | This broke on some smokers where the locale collation data was broken in some way (and rejected by the collation setup code.) It also broke if collation magic was generated for an SV and then the SV was modified, freeing the collation data before the SV was destroyed.
* add Perl_magic_freemglob() magic vtable methodDavid Mitchell2020-10-231-6/+21
| | | | | | | | | | | | | S_mg_free_struct() has a workaround to never free mg->mg_ptr for PERL_MAGIC_regex_global. Move this logic into a new magic vtable free method instead, so that S_mg_free_struct() (which gets called for every type of magic) doesn't have the overhead of checking every time for mg->mg_type == PERL_MAGIC_regex_global. [ No, I don't know why PERL_MAGIC_regex_global's vtable and methods are suffixed mglob rather than regex_global or vice versa ]
* add Perl_magic_freeutf8() magic vtable methodDavid Mitchell2020-10-231-1/+17
| | | | | | | | | | S_mg_free_struct() has a workaround to free mg->mg_ptr in PERL_MAGIC_utf8 even if mg_len is zero. Move this logic into a new magic vtable free method instead, so that S_mg_free_struct() (which gets called for every type of magic) doesn't have the overhead of checking every time for mg->mg_type == PERL_MAGIC_utf8.
* add Perl_magic_freecollxfrm() magic vtable methodDavid Mitchell2020-10-231-5/+16
| | | | | | | | | | v5.29.9-139-g44955e7de8 added a workaround to S_mg_free_struct() to free mg->mg_ptr in PERL_MAGIC_collxfrm even if mg_len is zero. Move this logic into a new magic vtable free method instead, so that S_mg_free_struct() (which gets called for every type of magic) doesn't have the overhead of checking every time for mg->mg_type == PERL_MAGIC_collxfrm.
* mg.c: Note that MAGIC is documented hereKarl Williamson2020-10-081-0/+2
|
* mg.c: Use SvTRUE instead of sv_trueKarl Williamson2020-09-051-1/+1
| | | | The former is preferred. This was the only sv_true() use in the core.
* Document whichsig and kinKarl Williamson2020-09-051-0/+25
|
* Reorganize perlapiKarl Williamson2020-09-041-1/+4
| | | | | This uses a new organization of sections that I came up with. I asked for comments on p5p, but there were none.
* Remove use of dVAR in coreDagfinn Ilmari Mannsåker2020-07-201-3/+0
| | | | | It only does anything under PERL_GLOBAL_STRUCT, which is gone. Keep the dNOOP defintion for CPAN back-compat
* fixup to free_and_set_cop_warnings()David Mitchell2020-03-201-3/+3
| | | | | | | | | | | | | | | | | | | v5.31.9-156-g94c8b9c1f0 introduced the free_and_set_cop_warnings() macro. It's first argument expects a COP rather than a COP*. Its usage in S_restore_cop_warnings(() is to modify PL_cucop, but in order to pass a COP rather than a COP*, the original commit made a local copy of PL_curcop and ended up inadvertently updating the copy instead. This commit changes the maco so it expects a COP*, and updates the bulk of its callers to use &PL_compiling rather than PL_compiling, and fixes up S_restore_cop_warnings(). The symptoms were ASAN failures in a few test scripts including uni/parser.t and ext/XS-APItest/t/handy0*.t. (The S_restore_cop_warnings() function was only used by Perl__force_out_malformed_utf8_message(), so didn't cause many issues outside of test scripts which forced such "malformed "errors).
* Add macro to free and set cop_warningsNicolas R2020-03-161-19/+13
| | | | | This is avoiding the boilerplate to free the cop_warning string when setting it.
* Pass the canonical signal name to the signal handler when it is invoked.Todd Rinaldo2020-02-041-1/+2
| | | | | | | | | | | | Prior to this change, when a signal handler was invoked, the signame passed into the sub would be the name of the signal that was defined first via {}. This meant that the handler had to either be aware of the duplicates and handle things appropriately or it would be at the mercy of action at a distance the handler might be unaware of. This change assures a consistent signal name for now on. It should be the first signal listed in $Config{sig_name}. Duplicates are listed at the end.
* updates to $^H{feature_validname} now update cop_featuresTony Cook2019-12-051-6/+7
| | | | This removes $^{FEATURE_BITS}, since it's no longer needed.
* Perl_csighandler(): remove forward declarationDavid Mitchell2019-11-181-7/+0
| | | | | There's a forward declaration of this function in mg.c. This should be redundant in these days of embed.fnc and embed.h, so remove it.
* Perl_perly_sighandler: re-indent some codeDavid Mitchell2019-11-181-38/+42
| | | | | | | Fix indentation after previous commits modified scopes; also indent some nested #if's correctly. Whitespace-only change
* Perl_perly_sighandler: combine two conditionsDavid Mitchell2019-11-181-3/+1
| | | | | | | | | The branch is only taken if a number of conditions are true. Combine them into a single if statement, with the sip test first, so that an unnecessary call to sigaction() may be skipped if its only going to immediately fail afterwards because sip isn't true. Shouldn't be any change in functionality.
* add explicit 1-arg and 3-arg sig handler functionsDavid Mitchell2019-11-181-2/+55
| | | | | | | Currently, whether the OS-level signal handler function is declared as 1-arg or 3-arg depends on the configuration. Add explicit versions of these functions, principally so that POSIX.xs can call which version of the handler it wants regardless of configuration: see next commit.
* fix unsafe signals under exceptionsDavid Mitchell2019-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | The preceding commit flagged up an existing bug, but kept old the buggy behaviour. This commit fixes the bug. I haven't added a test, since it seems that the test suite doesn't try with unsafe signals. But this code: $SIG{USR1} = sub { $gotit++, die }; eval { kill SIGUSR1, $$ } for 1..2; print "gotit=$gotit\n"; when run before erroneously gave 1, but now correctly gives 2. Basically the code that restores the signal mask after a sig handler dies, should do it only in a direct (unsafe) signal handler: the deferred (safe) signal handler will have already done it. The bug was that the inbuilt perl unsafe signal handler was being incorrectly treated as safe. The code path via POSIX (and for which a test was added with v5.13.9-531-gc22d665b55) *was* ok.
* add a new function, Perl_perly_sighandler()David Mitchell2019-11-181-9/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function implements the body of what used to be Perl_sighandler(), the latter becoming a thin wrapper round Perl_perly_sighandler(). The main reason for this change is that it allows us to add an extra arg, 'safe' to the function without breaking backcompat. This arg indicates whether the function is being called directly from the OS signal handler (safe==0), or deferred via Perl_despatch_signals() (safe==1). This allows an infelicity in the code to be fixed - it was formerly trying to determine the route it had been called by (and hence whether a 'safe' route) by seeing if either of the sig/uap parameters was non-null. It turns out that this was highly dogdy, and only worked by luck. The safe caller did indeed pass NULL args, but due to a bug (shortly to be fixed), sometimes the kernel thinks its calling a 1-arg sig handler when its actually calling a 3-arg one. This means that the sig/uap args are random garbage, and happen to be non-zero only by happy coincidence on the OS/platforms so far. Also, it turns out that the call via Perl_csighandler() was getting it wrong: its explicit (NULL,NULL) args made it look like a safe signal call. This will be corrected in the next commit, but for this commit the old wrong behaviour is preserved. See RT #82040 for details of when/why the original dodgy 'safe' check was added.
* add PERL_USE_3ARG_SIGHANDLER macroDavid Mitchell2019-11-181-6/+8
| | | | | | | | | | | | | | | | | | | | | | There are a bunch of places in core that do #if defined(HAS_SIGACTION) && defined(SA_SIGINFO) to decide whether the C signal handler function should be declared with, and called with, 1 arg or 3 args. This commit just adds #if defined(HAS_SIGACTION) && defined(SA_SIGINFO) # define PERL_USE_3ARG_SIGHANDLER #endif Then uses the new macro in all other places rather than checking HAS_SIGACTION and SA_SIGINFO. Thus there is no functional change; it just makes the code more readable. However, it turns out that all is not well with core's use of 1-arg versus 3-arg, and the few commits will fix this.
* add Siginfo_tDavid Mitchell2019-11-181-3/+3
| | | | | | | | | | | | | From the code comments: This is an alias for the OS's siginfo_t, except that where the OS doesn't support it, declare a dummy version instead. This allows us to have signal handler functions which always have a Siginfo_t parameter regardless of platform, (and which will just be passed a NULL value where the OS doesn't support HAS_SIGACTION). It doesn't actually do anything useful yet, but will shortly allow signal handler functions to be rationalised.
* Fix: local variable hiding parameter of same nameJames E Keenan2019-11-121-2/+2
| | | | | | | | | | | | | | | | LGTM provides static code analysis and recommendations for code quality improvements. Their recent run over the Perl 5 core distribution identified 12 instances where a local variable hid a parameter of the same name in an outer scope. The LGTM rule governing this situation can be found here: Per: https://lgtm.com/rules/2156240606/ This patch renames local variables in approximately 8 of those instances to comply with the LGTM recommendation. Suggestions for renamed variables were made by Tony Cook. For: https://github.com/Perl/perl5/pull/17281
* Faster feature checksTony Cook2019-10-301-2/+12
| | | | | | | | | | | | | | | Perform only a bit check instead of a much more expensive hash lookup to test features. For now I've just added a U32 to the cop structure to store the bits, if we need more we could either add more bits directly, or make it a pointer. We don't have the immediate need for a pointer that warning do since we don't dynamically add new features during compilation/runtime. The changes to %^H are retained so that caller() can be used from perl code to check the features enabled at a given caller's scope.
* (perl #134169) mg.c reset endptr after useManuel Mausz2019-06-191-1/+3
| | | | Perl_grok_atoUV has been changed so endptr constraints the input. Thus we need to reset the endptr after every use.
* The Windows CE Chainsaw MassacreSteve Hay2019-06-181-1/+1
| | | | | Remove WinCE support as agreed in the thread starting here: https://www.nntp.perl.org/group/perl.perl5.porters/2018/07/msg251683.html
* Remove redundant info on =for apidoc linesKarl Williamson2019-05-301-2/+2
| | | | | | | | | This information is already in embed.fnc, and we know it compiles. Some of this information is now out-of-date. Get rid of it. There was one bit of information that was (apparently) wrong in embed.fnc. The apidoc line asked that there be no usage example generated for newXS. I added that flag to the embed.fnc entry.
* fix locale leak on zero-length stringsDavid Mitchell2019-04-161-1/+7
| | | | | | | | | | | | | | | | | | | | For example the following leaked: use locale; my $le = "" le ""; When a comparison is done within locale scope, PERL_MAGIC_collxfrm magic is added to the SV. However, the value set for mg_len is the length of the collated string, not the malloced size of the buffer. This means that mg_len can be set to zero, which by convention, means that mg_ptr shouldn't be freed. For now, fix by putting special-cased code in S_mg_free_struct. After 5.30.0 is out, I'll probably add a PERL_MAGIC_collxfrm-specific svt_free vtable method. The symptoms were that valgrind / Address Sanitizer found fault with lib/locale.t
* fix leak with local ${^WARNING_BITS} = ...David Mitchell2019-03-251-0/+2
| | | | | | | | | | | | When restoring the old value, need to free the current value first. Can be reproduced with { local ${^WARNING_BITS} = 'swit'; } when run under ASan or similar. An equivalent test already exists in t/op/leaky-magic.t.
* grok_atoUV: allow non-C strings and documentKarl Williamson2018-06-251-1/+1
| | | | | | | | | | This changes the internal function grok_atoUV() to not require its input to be NUL-terminated. That means the existing calls to it must be changed to set the ending position before calling it, as some did already. This function is recommended to use in a couple of pods, but it wasn't documented in perlintern. This commit does that as well.
* mg.c: Fix isSCRIPT_RUN callKarl Williamson2018-03-021-2/+1
| | | | | Commit 49cd072660b3b1858be5f27df107b3b42498a3f3 failed to fix up this call to isSCRIPT_RUN, which is typically only compiled on Windows.
* ‘Nonelems’ for pushing sparse array on the stackFather Chrysostomos2018-02-181-0/+9
| | | | | | | | | | | | | | | | | To avoid having to create deferred elements every time a sparse array is pushed on to the stack, store a magic scalar in the array itself, which av_exists and refto recognise as not existing. This means there is only a one-time cost for putting such arrays on the stack. It also means that deferred elements that live long enough don’t start pointing to the wrong array entry if the array gets shifted (or unshifted/spliced) in the mean time. Instead, the scalar is already in the array, so it cannot lose its place. This fix only applies when the array as a whole is pushed on to the stack, but it could be extended in future commits to apply to other places where we currently use deferred elements.
* Add ${^SAFE_LOCALES}Karl Williamson2018-02-181-1/+13
| | | | | | | This read-only variable returns a boolean as to whether it is safe to use locales in this perl. Without threads it returns 1; when a future commit adds thread-safe locale handling, it will also return 1 if that is enabled.
* Add check that "$!" is correctly interpreted as UTF-8Karl Williamson2018-01-301-3/+9
| | | | | | | | | | | | | | We sometimes need to know if an error message is UTF-8 or not. Previously we checked that it is syntactically valid UTF-8, and that the LC_MESSAGES locale is UTF-8. But some systems, notably Windows, do not have LC_MESSAGES. For those, this commit adds a different, semantic, check that the text of the message when interpreted as UTF-8 is all in the same Unicode script. This is not foolproof, unlike the LC_MESSAGES check, but it's better than what we have now for such systems. It likely is foolproof for non-Latin locales, as any message will have a bunch of characters in that locale, and no ASCII Latin ones. For a Latin locale, these ASCII letters could be intermixed with the UTF-8 ones, causing potential ambiguity.
* Remove uncompilable codeKarl Williamson2018-01-301-7/+1
| | | | | | This code was never compiled because of a misspelling in the #ifdef. No problem surfaced, so just remove it. The next commit adds a different check.
* mg.c: Convert to use is_utf8_non_invariant_string()Karl Williamson2017-11-261-3/+2
|
* fix handling of registered warning categoriesZefram2017-11-151-22/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were some problems arising from some warning bitsets being shorter than others, which happens when registration of a new warning category makes new bitsets longer. Most obviously, if a scope used "use warnings 'all'" to turn on all warnings and then turned off some specific warnings, then that scope wouldn't get warnings for subsequently-registered warning categories, because its bitset doesn't extend to the bit controlling the new category. (If just "use warnings 'all'" was used, without any customisation, then a special hack made that work for new categories.) It was also possible for a longer bitset to get truncated by a warnings pragma, because the bitset editing code assumed that all bitsets are the same length. To fix this, first the warning bits for the "all" category have to change meaning. Unlike all other warning categories, the bits for "all" used to be set only when there were no warning categories disabled; disabling any would also clear the "all" bits. That was supporting the special hack mentioned above that the all-warnings bitset work for new categories. This exception is now removed, so the meaning of the "all" bits is now the more obvious meaning, of indicating the default treatment that the scope wants for warnings not falling into any category known to the bitset. In warnings::warnif() et al, if the caller's bitset is found to be too short to have a bit for the relevant category, then the setting for the "all" category is used instead. Because the length of a bitset is an integral number of bytes, but only two bits are used per category, the length of a bitset doesn't precisely indicate which categories had been registered by the time it was constructed. So the standard bitsets for the "all" category are now always filled to their byte length, with bits set preemptively for categories not yet registered that fall within the current bitset length. When a warnings pragma operates on a bitset, it first expands it to the preferred length, by duplicating the "all" bits for the categories covered by the new length. It is careful to maintain the length when combining the bitset with the standard bitsets for categories. When a bitset is read from ${^WARNING_BITS} or from caller(), the standard pWARN_ALL setting is no longer expanded by the core to $warnings::Bits{all}, because the core's short WARN_ALLstring will now be expanded correctly just like any other bitset. Fixes [perl #108778].
* store AV iterator as mg_len in more casesZefram2017-11-111-6/+6
| | | | | | | | | | | | | | | | | | | The iterator of an AV is an IV value attached to the AV via magic. It may be stored in the space used by mg_len, or it may be stored in separately allocated space referenced by mg_ptr. The former is more efficient, so should be preferred. The original code for AV iterators would use mg_len if IV was (the same size as) I32, because mg_len was of type I32. Since then mg_len has been increased to type SSize_t, but the conditional about how AV iterators are stored wasn't updated to match. As a result, on the now very common 64-bit builds we were missing out on the opportunity to use the more efficient form of storage. This commit updates the condition about how AV iterators are stored, to take account of the new type. In principle AV iterators ought to be of type SSize_t, and thus *always* storable as mg_len. But Perl_av_iter_p() is in the public API with its IV* return type, so there is a compatibility issue to address in changing that.
* mg.c: Use memchr instead of strchrKarl Williamson2017-11-061-2/+3
| | | | | This allows things to work properly in the face of embedded NULs. See the branch merge message for more information.
View Lorry Controller Status