summaryrefslogtreecommitdiff
path: root/sv.h
Commit message (Collapse)AuthorAgeFilesLines
* replace (0+(pointer)) with casts to the pointer typeTony Cook2022-07-181-2/+2
| | | | | Old versions (3.3.6) of gcc allowed assignment to such casts, but this is no longer an issue.
* Update comment in sv.h on the location of bodies_by_type[], since it was ↵Paul "LeoNerd" Evans2022-07-071-1/+1
| | | | moved to sv_inline.h
* Create `HvHasAUX()` macroPaul "LeoNerd" Evans2022-07-021-3/+2
| | | | | | | | Gives a new name `SVphv_HasAUX` to the `SVf_OOK` flag, for use on HVs. For back-compatibility with existing code we'll have to continue to use the same bit position, at least for now. But at least code can use this new name to be clearer about its intent.
* Eval param to SvPV-foo exactly onceKarl Williamson2022-06-291-119/+112
| | | | | This changes all the API macros that retrieve a PV into a call to an inline function so as to evaluate the parameter just once.
* Follow on to 6d21409fd4b749511b9ec73e2dbaaff513f6eae8Karl Williamson2022-06-181-57/+57
| | | | | This was meant to be a part of the previous commit, but somehow got omitted.
* Evaluate SET_SVANY_FOR_BODYLESS_[IN]V() param just onceKarl Williamson2022-06-131-4/+10
| | | | | | Since these are defined for just the core, we can add STMT_START { ... } STMT_END without repercussions
* Evaluate isGV_with_GP(on|off)() param just onceKarl Williamson2022-06-131-10/+17
|
* Evaluate Sv[INURU}V_set() params just onceKarl Williamson2022-06-131-19/+34
|
* Evaluate SvSetSV_(nosteal_)?and() params just onceKarl Williamson2022-06-131-4/+12
|
* Evaluate SvIV_please() param just onceKarl Williamson2022-06-131-2/+5
|
* Evaluate SvREFCNT_inc_simple_void() param just onceKarl Williamson2022-06-131-1/+7
|
* SvGETMAGIC: evaluate its argument just onceKarl Williamson2022-06-101-6/+0
| | | | | | | This required making it into an inline function. I tried using STMT_START{ ... } STMT_END, which should work since it has a void return, but there were places where it was used in a comma operator, and those did not compile.
* Change SvIV and kin to inline functionsKarl Williamson2022-05-281-62/+4
| | | | So that they will evaluate the argument just once.
* perlapi: Add pod link to newly documented macrosKarl Williamson2022-05-281-2/+2
|
* Evaluate SvPVXtrue's argument just onceKarl Williamson2022-05-281-24/+0
| | | | by making the macro instead an inline function
* Change formal macro parameter nameKarl Williamson2022-05-271-2/+2
| | | | This makes it match all the similar functions.
* perlapi: Document SvPV_shrink_to_curKarl Williamson2022-05-271-0/+13
|
* perlapi: Document SV_CHECK_THINKFIRST*Karl Williamson2022-05-271-5/+24
|
* sv.c - add new bool related utility functions and macrosYves Orton2022-05-271-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* perlapi: Document SvAMAGICKarl Williamson2022-05-191-0/+9
|
* perlapi: newIO should be in IO sectionKarl Williamson2022-05-081-0/+1
|
* perlapi: Document newIOKarl Williamson2022-05-071-0/+7
|
* perlapi,perlintern: Add tainting sectionKarl Williamson2022-05-061-0/+2
| | | | | | Tainting is so specialized that things dealing with it are better gathered together in one place. This commit moves the existing docs for such API into the new section
* perlapi: Document SvPVXtrueKarl Williamson2022-04-251-1/+14
|
* perlapi: Rmv duplicate entriesKarl Williamson2022-04-231-39/+0
| | | | | | These entries that are minor variants of each other were consolidated into one over-arching entry, but the individual ones were inadvertently retained, leading to duplicate information.
* Make newSV_type an inline functionRichard Leach2022-03-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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);
* Update SvPV() etc to avoid calling sv_2pv_flags() for cached IV strings.Nicholas Clark2022-02-191-7/+18
| | | | | This "teaches" them the new SV flags combination implemented by the previous commit.
* Create sv_streq() API family, as a stringy copy of the sv_numeq() onesPaul "LeoNerd" Evans2022-01-271-0/+1
|
* Initial implementation of sv_numeq() and _flags() variantPaul "LeoNerd" Evans2022-01-261-0/+1
|
* Split the XPVHV body into two variants "normal" and "with aux"Nicholas Clark2021-10-111-1/+5
| | | | | | | | Default to the smaller body, and switch to the larger body if we need to allocate a C<struct xpvhv_aux> (eg need an iterator). This restores the previous small size optimisation for hashes used as objects.
* Rename HE_SVSLOT to HE_ARENA_ROOT_IXNicholas Clark2021-10-111-5/+3
| | | | | | The longer name more accurately reflects what the constant refers to. Correct the comments describing how some arena roots are re-used.
* SvIsBOOL's return type of 'bool' must be lowercase in =apidoc linePaul "LeoNerd" Evans2021-09-111-1/+1
|
* Add SvIsBOOL() macro to test for SVs being boolean-intentPaul "LeoNerd" Evans2021-09-101-0/+26
| | | | | | | | | | | These are identified as being static shared COW strings whose string buffer points directly at PL_Yes / PL_No Define sv_setbool() and sv_setbool_mg() macros Use sv_setbool() where appropriate Have sv_dump() annotate when an SV's PV buffer is one of the PL_(Yes|No) special booleans
* Define a third kind of COW state; STATICPaul "LeoNerd" Evans2021-09-101-4/+7
| | | | | | | | | | | | | | | | | | | | Previously, when IsCOW flag was set there were two cases: SvLEN()==0: PV is really a shared HEK SvLEN()!=0: PV is a COW structure with 1..256 refcount stored in its extra final byte This change adds a third state: SvLEN()==0 && SvFLAGS() & SVppv_STATIC: PV is a shared static const pointer and must not be modified sv_setsv_flags() and sv_setsv_cow() will preserve this state sv_uncow() will copy it out to a regular string buffer sv_dup() will preserve the static pointer into cloned threads
* Base *.[ch] files: Replace leading tabs with blanksMichael G Schwern2021-05-311-333/+333
| | | | | | | This is a rebasing by @khw of part of GH #18792, which I needed to get in now to proceed with other commits. It also strips trailing white space from the affected files.
* Docs: Emphasize SvPVbyte and SvPVutf8 over SvPV. This updatesFelipe Gasper2021-04-141-3/+13
| | | | | | perlguts, perlxs, perlxstut, and perlapi. Issue #18600
* perlapi: link to SvPVKarl Williamson2020-12-301-2/+2
|
* perlapi: Consolidate newRV and newRV_inc podKarl Williamson2020-12-301-3/+4
|
* perlapi: Two references aren't yet linksKarl Williamson2020-12-271-2/+2
| | | | This was causing a podcheck error
* Document SvPV_renewKarl Williamson2020-12-271-0/+11
|
* perlapi: SvPVbyte_force() and kin: clarify.Karl Williamson2020-12-201-8/+11
|
* perlapi: Document and consolidate SvPV functionsKarl Williamson2020-12-201-40/+87
|
* perlapi: Remove duplicate textKarl Williamson2020-12-131-3/+0
| | | | This came about in a rebasing error
* Document and consolidate SvPV..force functionsKarl Williamson2020-12-131-14/+45
|
* perlapi: Consolidate SvSET-ish entriesKarl Williamson2020-12-061-10/+13
| | | | These should also be in the SV section instead of Magic
* Evaluate arg once in all forms of SvTRUEKarl Williamson2020-12-061-35/+26
| | | | 5.32 did this for one form; now all do.
* Document SvSHARED_HASHKarl Williamson2020-11-291-0/+6
|
* perlapi: Consolidate svREFCNT_dec-ish entriesKarl Williamson2020-11-291-5/+4
|
* perlapi: Consolidate SvPVX-ish entriesKarl Williamson2020-11-291-4/+16
|
* perlapi: Consolidate SvREFCNT_INC-ish entriesKarl Williamson2020-11-281-28/+27
|
View Lorry Controller Status