summaryrefslogtreecommitdiff
path: root/sv.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Add a new env var PERL_RAND_SEEDYves Orton2022-08-121-0/+2
| | | | | | | | | | | | | | | | | | | | | This env var can be used to trigger a repeatable run of a script which calls C<srand()> with no arguments, either explicitly or implicitly via use of C<rand()> prior to calling srand(). This is implemented in such a way that calling C<srand()> with no arguments in forks or subthreads (again explicitly or implicitly) will receive their own seed but the seeds they receive will be repeatable. This is intended for debugging and perl development performance testing, and for running the test suite consistently. It is documented that the exact seeds used to initialize the random state are unspecified, and that they may change between releases or even builds. The only guarantee provided is that the same perl executable will produce the same results twice all other things being equal. In practice and in core testing we do expect consistency, but adding the tightest set of restrictions on our commitments seemed sensible. The env var is ignored when perl is run setuid or setgid similarly to the C<PERL_INTERNAL_RAND_SEED> env var.
* locale.c: Add fcn to hide edge case undefined behaviorKarl Williamson2022-08-091-0/+3
| | | | | | | | | | | | The POSIX 2008 API has an edge case in that the result of most of the functions when called with a global (as opposed to a per-thread) locale is undefined. The duplocale() function is the exception which will create a per-thread locale containing the values copied from the global one. This commit just calls duplocale, if needed, and the caller need not concern itself with this possibility
* sv.c: Duplicate more variables during cloningKarl Williamson2022-08-091-2/+6
| | | | | These locale-related ones should be getting initialized in the new thread, but be certain.
* locale.c: Generalize stdize_locale()Karl Williamson2022-08-091-0/+3
| | | | | | | | | | | | | | | | | | | | This function is rewritten to handle LC_ALL, and to make it easier to add new checks. There is also a change, which I think is an improvement, in that everything starting with a \n is trimmed, instead of just a trailing \n. A couple of calls to stdize_locale() are removed, as they are redundant, because they are called only as a result of Perl_setlocale() being called, and that ends up calling stdize_locale always, early on. The call to savepv() is also moved in a couple cases to after the result is known to not be NULL I originally had such a new check in mind, but it turned out that doing it here didn't solve the problem, so this commit has been amended (before ever being pushed) to not include that. chomped.
* sv.c: Move some initialization inside #ifdefKarl Williamson2022-08-091-2/+2
| | | | If not using the feature, don't need to initialize it.
* explicitly ignore the result of sv_utf8_downgrade()Tony Cook2022-08-081-1/+1
| | | | | | | Coverity complains about this because most other calls are checked. CIDs 353483, 353003, 353000, 352998, 352995
* Replace sv_2mortal(newSVhek( with newSVhek_mortalRichard Leach2022-08-051-1/+1
| | | | The new Perl_newSVhek_mortal function is slightly more efficient.
* sv.c - add Perl_newSVhek_mortalRichard Leach2022-08-051-0/+24
| | | | | | | | This is a small wrapper function intended to replace use of sv_2mortal(newSVhek(...)) This provides some small optimization, since sv_2mortal performs a number of checks for conditions that we know cannot be true.
* Perl_newRV_noinc - explicitly simplify, convert to inline funcRichard Leach2022-08-051-33/+0
| | | | | | | | | | | | Perl_newRV_noinc creates a new SVt_IV, then calls sv_setrv_noinc, which will check if the SVt_IV is SvTHINKFIRST (it won't be) and if it is types other than SVt_IV (it won't be). If those checks and associated branches are removed, all that remains is some flag twiddling and setting the sv_u.svu_rv pointer. A decent compiler *might* figure that all out and simplify Perl_newRV_noinc right down to the essentials, but if we do that directly, the entire function is small enough to move to sv_inline.h
* sv_resetpvn: prevent adding a zero offset to a NULL pointerTony Cook2022-07-181-1/+1
|
* perl.h: Change macro name to be C conformantKarl Williamson2022-07-111-1/+1
| | | | Leading underscores in names are undefined
* Use HvHasAUX() rather than SvOOK() when operating on HVsPaul "LeoNerd" Evans2022-07-021-8/+8
|
* sv.c: Replace a runtime check with compile-time static assertionTAKAI Kousuke2022-07-011-5/+6
| | | | | | | | | The original code used to check U_V(Perl_fabs(SvNVX(sv))) < (UV)IV_MAX in runtime, but possibility of failing this check will imply that such perl configuration is unusable anyway. To make this check never fail, the first non-preserved integer, which is (1 << NV_PRESERVES_UV_BITS), is required to be less than (or equal to) IV_MAX, which can be checked at compile time without runtime overhead.
* sv.c: Use Perl_fabs rather than hand-coded abs expressionsTAKAI Kousuke2022-07-011-6/+4
| | | | | | Same as the commit 644e3ee3290a8de5f7fc90ae85ae5c96a2a00039, Perl_fabs is usually faster and compacter than hand-coded abs (conditional negation) on modern environments.
* perlintern: report_uninit() goes in warnings scnKarl Williamson2022-06-281-0/+1
|
* Follow on to 6d21409fd4b749511b9ec73e2dbaaff513f6eae8Karl Williamson2022-06-181-12/+12
| | | | | This was meant to be a part of the previous commit, but somehow got omitted.
* GH19478: applying taint is no reason to mess with posHugo van der Sanden2022-06-161-10/+0
| | | | | | | | | | | | | | 25fdce4a16 introduced a chunk in sv_magic() to "force pos to be stored as characters, not bytes" whenever any magic was applied to a string marked UTF8. It is not clear why a random call to sv_magic(), eg to mark a string as tainted, needs to do this - it would seem more logical for the check to happen either earlier (when the string first qualifies as SvMAGICAL(sv) && DO_UTF8(sv)) or later (eg on mg_find). Experimentally remove this block - it appears to cause no test failures, and allows the new test cases to pass.
* Regularize HAS_POSIX_2008_LOCALE, USE_POSIX_2008_LOCALEKarl Williamson2022-06-161-1/+1
| | | | | | | | | A platform shouldn't be required to use the Posix 2008 locale handling functions if they are present. Perhaps they are buggy. So, a separate define for using them was introduced, USE_POSIX_2008_LOCALE. But until this commit there were cases that were looking at the underlying availability of the functions, not if the Configuration called for their use.
* Change handy.h macro names to be C standard conformantKarl Williamson2022-06-121-3/+3
| | | | | | | C reserves symbols beginning with underscores for its own use. This commit moves the underscore so it is trailing, which is legal. The symbols changed here are many of the ones in handy.h that have significant uses outside it.
* Make fc(), qr//i thread-safe on participating platformsKarl Williamson2022-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A long standing bug in Perl that has gone undetected is that the array is global that is created when changing locales and tells fc() and qr//i matching what the folds are in the new locale. What this means is that any program only has one set of fold definitions that apply to all threads within it, even if we claim that the locales are thread-safe on the given platform. One possibility for this going undetected so long is that no one is using locales on multi-threaded systems much. Another possibility is that modern UTF-8 locales have the same set of folds as any other one. It is a simple matter to make the fold array per-thread instead of per-process, and that solves the problem transparently to other code. I discovered this stress-testing locale handling under threads. That test will be added in a future commit. In order to keep from having a dTHX inside foldEQ_locale, it has to have a pTHX_ parameter. This means that the other functions that function pointer variables get assigned to point to have to have an identical signature, which means adding pTHX_ to functions that don't require it. The bodies of all these are known to the compiler, since they are all in inline.h or in the same .c file as where they are called. Hence the compiler can optimize out the unused parameter. Two calls of STR_WITH_LEN also have to be changed because of C preprocessor limitations; perhaps there is another way to do it that I'm unfamiliar with.
* Make use of av_push_simple in a few places.Richard Leach2022-06-081-5/+7
| | | | | | | | | Specifically, only where a new AV has just been created and it's therefore obvious that av_push_simple is safe to use. In many cases, nearby code does av_push to an existing array. It might well be the case that these are simple arrays and av_push_simple could be used instead. The necessary analysis has been left for the future.
* Remove deprecated functionsKarl Williamson2022-06-051-48/+0
| | | | | Most of these have been deprecated for a long time; and we've never bothered to follow through in removing them. This commit does that.
* make PL_origenviron globalTomasz Konojacki2022-05-291-1/+0
| | | | | The purpose of PL_origenviron is to preserve the earliest known value of environ, which is a global. All interpreters should share it.
* sv.c - add new bool related utility functions and macrosYves Orton2022-05-271-0/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new bool "type" does not have the usual complement of utility functions and macros. It only has one encapsulating function, which is perfectly reasonable for most use cases where one wants to test if an SV* is a bool, but does a bit too much if one is working on a serialization tool which is likely to want to unroll a nice chunk of the logic. The new type also lacks the usual cohort of utility functions to create new bool SV's. This patch adds the following functions: newSVbool(const bool bool_val) newSV_true() newSV_false() sv_set_true(SV *sv) sv_set_false(SV *sv) sv_set_bool(SV *sv, const bool bool_val) And the following macros: SvIandPOK(sv) SvIandPOK_off(sv) SvIandPOK_on(sv) The following three are intended very specifically for writing serialization code like for Sereal, where it is reasonable to want to unroll the logic contained in Perl_sv_isbool() and SvTRUE(). They are documented as "you dont want to use this except under special circumstances". SvBoolFlagsOK(sv) BOOL_INTERNALS_sv_isbool(sv) BOOL_INTERNALS_sv_isbool_true(sv) BOOL_INTERNALS_sv_isbool_false(sv) SvBoolFlagsOK() is documented as being the same as SvIandPOK(), but this abstracts the intent from the implementation.
* Revert "perlapi: Document sv_dup(_inc)?"Karl Williamson2022-05-211-21/+0
| | | | | This reverts commit f45ba102ff7bfce07641cfd49cd18ef4e8a7f6e3, which turns out to be contentious, so at this late date revert.
* perlapi: Document sv_dup(_inc)?Karl Williamson2022-05-201-0/+21
|
* perlapi: Turn ptr_table comments into podKarl Williamson2022-05-191-6/+41
|
* perlapi: Document several *_dup functionsKarl Williamson2022-05-181-6/+46
|
* perlapi: Properly cross link to other elementsKarl Williamson2022-05-171-3/+4
|
* perlapi: Slight clarification in sv_setpvfKarl Williamson2022-05-171-2/+2
|
* perlapi: Remove extraneous infoKarl Williamson2022-05-081-1/+0
| | | | | The text below the line removed was inadvertently presumed to be part of perlapi.
* perlapi: Consolidate sv_usepvn(_flags)? entriesKarl Williamson2022-05-081-15/+26
|
* perlapi: Restore sv_2pv_flags to be public; doc sv_2pvKarl Williamson2022-05-081-6/+14
| | | | | | | | | | | Commit baf0bea7d35c79152c97fb52ffa5762ff103351d marked the _flags version as internal, leaving sv_2pv undocumented. There are macros that wrap these, some with extra functionality, but it turns out that these have long been considered API. There are a few uses of them on CPAN. This documents both, noting that the macros are preferred
* Document sv_2pv(byte|utf8)_flagsKarl Williamson2022-05-081-11/+24
|
* perlapi: Consolidate sv_setpv entriesKarl Williamson2022-05-081-22/+21
| | | | | | Making these a single entry makes perlapi more concise with less repetition, and clarifies the similarities and distinctions between the variant forms.
* perlapi: Create proper hyperlinkKarl Williamson2022-05-061-1/+1
|
* perlapi: Fix misspellingKarl Williamson2022-05-021-1/+1
|
* fix SVf_POK getting set on NVs when copyingGraham Knop2022-04-121-0/+10
| | | | | | | | | | | | | | | | When copying an SV with SVp_POK set, the SVf_POK flag gets enabled on the destination SV in all cases, to allow some of the COW logic to work properly. The flag is then meant to be disabled later in the routine, if the original SV was not SVp_POK. This was happening for IOK values, but not NOK values. This would only impact a few values (Inf, -Inf, NaN) as the string form of other floats is sensitive to locale so would not be stored. In the past, values like this would also always have SVf_POK set, but this has recently been changed to allow tracking the origin type of a value, exposing this bug. Fix this by checking for this case and unsetting the flag as appropriate for SVf_NOK values, the same as was previously being done for SVf_IOK values.
* Perl_newSViv: simplify by using (inline) newSV_typeRichard Leach2022-03-201-14/+1
|
* Perl_newSVnv: simplify SV creation and SvNV_setRichard Leach2022-03-201-3/+5
| | | | | | | | | The function can be simplified by using the now-inlined newSV_type function, directly using SvNV_set, and twiddling the required flags. This cuts out any function call overhead, a switch statement leading to a sv_upgrade(sv, SVt_NV) call, and a touch more bit-twiddling than is necessary.
* Rename HVhek_UNSHARED to HVhek_NOTSHAREDNicholas Clark2022-03-191-2/+2
| | | | | | | | | | | | | | "HVhek_UNSHARED" marked unshared HEKs - allocated directly with malloc(), rather then from the shared string table, and released with free(). But *shared* HEKs (in the shared string table) are released by calling unshare_hek(), whilst unshared HEKs should never go near this. So rename them to "not shared", to avoid this confusion. Change their flag bit from 0x08 to 0x04 to remove a gap. 0x04 had previously been used to flag "REHASH", which was removed before v5.18.0 Move the definition of the macro HVhek_MASK from hv.h to hv.c
* Use each HEK's own flags to decide "shared or not", instead of the HV'sNicholas Clark2022-03-191-5/+3
| | | | | | | Previously it was assumed that a hash with HvSHAREKEYS() true could only contain shared HEKs, and a hash with it false always contained only unshared HEKs. As HEKs all contain a flag bit to indicated "shared or not", instead use that to take decisions on how to dup or free them.
* always prevent setting POK flag when NV values are used as stringsGraham Knop2022-03-151-2/+2
| | | | | | | | | | | | | | | | Since PR #18958, values that start as IVs will not get their POK flags set when they are used as strings. This is meant to aid in serialization, allowing the "original" type of a value to be preserved. For NV values, the POK flag was already usually not being set, because the string form of a float could change based on the locale changing. However, for Inf and NaN values, the POK flag would still be enabled. Also, POK would be set for all floats if USE_LOCALE_NUMERIC was not defined. Update Perl_sv_2pv_flags to only enable the POKp flag when storing the PV for Inf or NaN values, or all NVs when USE_LOCALE_NUMERIC is not defined.
* Inlined newSV_type(SVt_NULL) leaner than non-inlined newSV(0)Richard Leach2022-03-071-2/+2
| | | | | | | | | | | | When a function outside of sv.c creates a SV via newSV(0): * There is a call to Perl_newSV * A SV head is uprooted and its flags set * A runtime check is made to effectively see if 0 > 0 * The new SV* is returned Replacing newSV(0) with newSV_type(SVt_NULL) should be more efficient, because (assuming there are SV heads to uproot), the only step is: * A SV head is uprooted and its flags set
* Make newSV_type an inline functionRichard Leach2022-03-071-356/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a new SV is created and upgraded to a type known at compile time, uprooting a SV head and then using the general-purpose upgrade function (sv_upgrade) is clunky. Specifically, while uprooting a SV head is lightweight (assuming there are unused SVs), sv_upgrade is too big to be inlined, contains many branches that can logically be resolved at compile time for known start & end types, and the lookup of the correct body_details struct may add CPU cycles. This commit tries to address that by making newSV_type an inline function and including only the parts of sv_upgrade needed to upgrade a SVt_NULL. When the destination type is known at compile time, a decent compiler will inline a call to newSV_type and use the type information to throw away all the irrelevant parts of the sv_upgrade logic. Because of the spread of type definitions across header files, it did not seem possible to make the necessary changed inside sv.h, and so a new header file (sv_inline.h) was created. For the inlined function to work outside of sv.c, many definitions from that file were moved to sv_inline.h. Finally, in order to also benefit from this change, existing code in sv.c that does things like this: SV* sv; new_SV(sv); sv_upgrade(sv, SVt_PV) has been modified to read something like: SV* sv = newSV_type(SVt_PV);
* sv.c: reuse NV-to-IV/UV conversion code for SV-to-NV-to-IV/UV conversionTAKAI Kousuke2022-03-041-35/+5
| | | | | | | S_sv_2iuv_common() had two NV to IV/UV conversion code, one is used when input is NOKp, another is used when converting a string to IV/UV via NV (as long as NV_PRESERVES_UV is defined). These two conversions should be identical, so sharing one code will be clearer and make code a bit compact.
* Make sv_len_utf8_nomg() publicKarl Williamson2022-03-021-2/+5
| | | | | | | | | | | | | | | The get-magic version of this has long been available, but not the no magic. It turns out that ppport.h does make both available, so any module using that would be able to use it anyway, without even noticing that it isn't supported by core. I see no reason for this to not be public; the original commit message did not indicate such a reason, and it is effectively public anyway via ppport.h. (This is the only non-publically accessible function that ppport.h furnishes; I'm working on a patch to have it warn of future instances creeping in.)
* Copy values that are "written as IV, then read as PV" with the same flags.Nicholas Clark2022-02-191-0/+6
| | | | | | Previously Perl_sv_setsv_flags() would gleefully turn on SVf_POK for these values, which meant that any copy no longer propagated the (new) state that says "this value started as an integer".
* Update SvPV() etc to avoid calling sv_2pv_flags() for cached IV strings.Nicholas Clark2022-02-191-4/+7
| | | | | This "teaches" them the new SV flags combination implemented by the previous commit.
* Don't set SVf_POK in Perl_sv_2pv_flags() when caching the string for an IV.Nicholas Clark2022-02-191-1/+13
| | | | | | | | | | | This permits XS code (such as serialisers) to distinguish between values that started as IVs but had a string representation cached, and values that started as PVs but had an (exact) integer representation cached. As implemented, the change in flags means that Perl_sv_2pv_flags() will be entered each time the string for an IV is wanted. The next commit will fix SvPV() and the other macros to avoid calling Perl_sv_2pv_flags() more than once, restoring the previous behaviour.
View Lorry Controller Status