Skip Menu |
Report information
Id: 132964
Status: pending release
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: pali [at] cpan.org
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)

Attachments
0001-Add-newSVsv_nomg-macro-which-is-like-newSVsv-but-doe.patch
0001-Make-sv_mortalcopy_flags-public.patch
v2-0001-Add-newSVsv_nomg-macro-which-is-like-newSVsv-but-doe.patch



Date: Mon, 12 Mar 2018 10:59:55 +0100
To: perlbug [...] perl.org
Subject: Missing newSVsv_nomg macro variant
From: pali [...] cpan.org
Download (untitled) / with headers
text/plain 1.7k
Hi! In perl XS api is missing function which creates a copy of the scalar without processing get magic and without destroying source scalar when is mortal. It is needed in situation when you want to call other perl function (via call_pv()) with scalar argument which comes from the argument passed to the current XS function (e.g. ST(0)) on which was already called SvGETMAGIC() and it is needed to prevent modification of it argument (e.g. because it is used also after call_pv() call). Table of available functions: magic steal mortal target source source target sv_setsv() X X sv_setsv_mg() X X X sv_setsv_nomg() X SvSetMagicSV() X X X SvSetMagicSV_nosteal() X X SvSetSV() X X SvSetSV_nosteal() X sv_mortalcopy() X X X newSVsv() X sv_setsv_flags() CAN CAN CAN Function which would create a copy of the scalar without processing get magic and without destroying (stealing) source scalar can be caller newSVsv_nomg() (according to to other _nomg names). Primitive implementation is there: static SV *newSVsv_nomg(SV *sv) { SV *ret = newSV(0); sv_setsv_flags(ret, sv, SV_NOSTEAL); return ret; } For above case with call_pv() can be useful function like newSVsv_nomg(), but which would return mortal copy. Based on above used naming scheme, I would propose sv_mortalcopy_nosteal_nomg(). Primitive implementation: static SV *sv_mortalcopy_nosteal_nomg(SV *sv) { SV *ret = sv_newmortal(); sv_setsv_flags(ret, sv, SV_NOSTEAL); return ret; } Please consider implementing these two functions into perl.h/perlapi.
From: pali [...] cpan.org
Date: Thu, 9 Aug 2018 13:22:18 +0200
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 2.2k
On Monday 12 March 2018 10:59:55 pali@cpan.org wrote: Show quoted text
> Hi! In perl XS api is missing function which creates a copy of the > scalar without processing get magic and without destroying source scalar > when is mortal. > > It is needed in situation when you want to call other perl function (via > call_pv()) with scalar argument which comes from the argument passed to > the current XS function (e.g. ST(0)) on which was already called > SvGETMAGIC() and it is needed to prevent modification of it argument > (e.g. because it is used also after call_pv() call). > > Table of available functions: > > magic steal mortal > target source source target > sv_setsv() X X > sv_setsv_mg() X X X > sv_setsv_nomg() X > SvSetMagicSV() X X X > SvSetMagicSV_nosteal() X X > SvSetSV() X X > SvSetSV_nosteal() X > sv_mortalcopy() X X X > newSVsv() X > sv_setsv_flags() CAN CAN CAN > > Function which would create a copy of the scalar without processing get > magic and without destroying (stealing) source scalar can be caller > newSVsv_nomg() (according to to other _nomg names). > > Primitive implementation is there: > > static SV *newSVsv_nomg(SV *sv) { > SV *ret = newSV(0); > sv_setsv_flags(ret, sv, SV_NOSTEAL); > return ret; > } > > For above case with call_pv() can be useful function like > newSVsv_nomg(), but which would return mortal copy. Based on above used > naming scheme, I would propose sv_mortalcopy_nosteal_nomg(). > > Primitive implementation: > > static SV *sv_mortalcopy_nosteal_nomg(SV *sv) { > SV *ret = sv_newmortal(); > sv_setsv_flags(ret, sv, SV_NOSTEAL); > return ret; > } > > Please consider implementing these two functions into perl.h/perlapi.
Now I found that in blead is undocumented macro sv_mortalcopy_flags and function Perl_sv_mortalcopy_flags() which could potentially replace that idea for sv_mortalcopy_nosteal_nomg(). So what about documenting macro sv_mortalcopy_flags and making it public? Also there is still a need for newSVsv_nomg()-like function or macro.
From: pali [...] cpan.org
Date: Mon, 21 Jan 2019 10:03:47 +0100
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 2.5k
On Thursday 09 August 2018 13:22:18 pali@cpan.org wrote: Show quoted text
> On Monday 12 March 2018 10:59:55 pali@cpan.org wrote:
> > Hi! In perl XS api is missing function which creates a copy of the > > scalar without processing get magic and without destroying source scalar > > when is mortal. > > > > It is needed in situation when you want to call other perl function (via > > call_pv()) with scalar argument which comes from the argument passed to > > the current XS function (e.g. ST(0)) on which was already called > > SvGETMAGIC() and it is needed to prevent modification of it argument > > (e.g. because it is used also after call_pv() call). > > > > Table of available functions: > > > > magic steal mortal > > target source source target > > sv_setsv() X X > > sv_setsv_mg() X X X > > sv_setsv_nomg() X > > SvSetMagicSV() X X X > > SvSetMagicSV_nosteal() X X > > SvSetSV() X X > > SvSetSV_nosteal() X > > sv_mortalcopy() X X X > > newSVsv() X > > sv_setsv_flags() CAN CAN CAN > > > > Function which would create a copy of the scalar without processing get > > magic and without destroying (stealing) source scalar can be caller > > newSVsv_nomg() (according to to other _nomg names). > > > > Primitive implementation is there: > > > > static SV *newSVsv_nomg(SV *sv) { > > SV *ret = newSV(0); > > sv_setsv_flags(ret, sv, SV_NOSTEAL); > > return ret; > > } > > > > For above case with call_pv() can be useful function like > > newSVsv_nomg(), but which would return mortal copy. Based on above used > > naming scheme, I would propose sv_mortalcopy_nosteal_nomg(). > > > > Primitive implementation: > > > > static SV *sv_mortalcopy_nosteal_nomg(SV *sv) { > > SV *ret = sv_newmortal(); > > sv_setsv_flags(ret, sv, SV_NOSTEAL); > > return ret; > > } > > > > Please consider implementing these two functions into perl.h/perlapi.
> > Now I found that in blead is undocumented macro sv_mortalcopy_flags and > function Perl_sv_mortalcopy_flags() which could potentially replace that > idea for sv_mortalcopy_nosteal_nomg(). So what about documenting macro > sv_mortalcopy_flags and making it public? > > Also there is still a need for newSVsv_nomg()-like function or macro.
Hi! Any comments for making Perl_sv_mortalcopy_flags() function public? And for providing newSVsv_nomg()-like function?
From: pali [...] cpan.org
Date: Thu, 7 Feb 2019 14:22:28 +0100
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 114b
In attachment is implementation of newSVsv_nomg() variant macro which does not process get magic on input scalar.

Message body is not shown because sender requested not to inline it.

From: pali [...] cpan.org
Date: Thu, 7 Feb 2019 14:28:56 +0100
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
To: perlbug-followup [...] perl.org
And here is patch which makes sv_mortalcopy_flags() function public.

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 292b
On Thu, 07 Feb 2019 05:22:52 -0800, pali@cpan.org wrote: Show quoted text
> In attachment is implementation of newSVsv_nomg() variant macro which > does not process get magic on input scalar.
Why not make SV_NOSTEAL significant for newSVsv_flags() ? Otherwise it will be messy adding it in the future. Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 313b
On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote: Show quoted text
> And here is patch which makes sv_mortalcopy_flags() function public.
+=for apidoc sv_mortalcopy_flags + +Like C<sv_mortalcopy>, but the extra C<flags> are passed to the +C<sv_setsv_flags>. + SV_GMAGIC is also meaningful for sv_mortalcopy_flags(). Tony
Date: Wed, 13 Feb 2019 20:16:03 +0100
From: pali [...] cpan.org
To: perlbug-followup [...] perl.org
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
Download (untitled) / with headers
text/plain 441b
On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote: Show quoted text
> On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > And here is patch which makes sv_mortalcopy_flags() function public.
> > +=for apidoc sv_mortalcopy_flags > + > +Like C<sv_mortalcopy>, but the extra C<flags> are passed to the > +C<sv_setsv_flags>. > + > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
So... any suggestion how to improve documentation?
From: pali [...] cpan.org
Date: Thu, 14 Feb 2019 12:46:03 +0100
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 516b
On Tuesday 12 February 2019 20:08:47 Tony Cook via RT wrote: Show quoted text
> On Thu, 07 Feb 2019 05:22:52 -0800, pali@cpan.org wrote:
> > In attachment is implementation of newSVsv_nomg() variant macro which > > does not process get magic on input scalar.
> > Why not make SV_NOSTEAL significant for newSVsv_flags() ? > > Otherwise it will be messy adding it in the future.
Ok. In attachment is updated V2 patch which supports all flags like sv_setsv_flags() function. So not only SV_NOSTEAL, but also SV_COW_SHARED_HASH_KEYS.

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 665b
On Thu, 14 Feb 2019 03:46:17 -0800, pali@cpan.org wrote: Show quoted text
> On Tuesday 12 February 2019 20:08:47 Tony Cook via RT wrote:
> > On Thu, 07 Feb 2019 05:22:52 -0800, pali@cpan.org wrote:
> > > In attachment is implementation of newSVsv_nomg() variant macro which > > > does not process get magic on input scalar.
> > > > Why not make SV_NOSTEAL significant for newSVsv_flags() ? > > > > Otherwise it will be messy adding it in the future.
> > Ok. In attachment is updated V2 patch which supports all flags like > sv_setsv_flags() function. So not only SV_NOSTEAL, but also > SV_COW_SHARED_HASH_KEYS.
Thanks, applied as 238f2c136aa0ab2a1070f175ec56ef61b91ff79d. Tony
To: perlbug-followup [...] perl.org
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
Date: Tue, 26 Feb 2019 10:00:58 +0100
From: pali [...] cpan.org
Download (untitled) / with headers
text/plain 602b
On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote: Show quoted text
> On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > And here is patch which makes sv_mortalcopy_flags() function public.
> > > > +=for apidoc sv_mortalcopy_flags > > + > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed to the > > +C<sv_setsv_flags>. > > + > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > So... any suggestion how to improve documentation?
Tony, ping. What do you prefer or how do you want to improve this change?
From: pali [...] cpan.org
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
To: perlbug-followup [...] perl.org
Date: Thu, 28 Mar 2019 13:58:08 +0100
Download (untitled) / with headers
text/plain 698b
On Tuesday 26 February 2019 10:00:58 pali@cpan.org wrote: Show quoted text
> On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote:
> > On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > > And here is patch which makes sv_mortalcopy_flags() function public.
> > > > > > +=for apidoc sv_mortalcopy_flags > > > + > > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed to the > > > +C<sv_setsv_flags>. > > > + > > > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > > > So... any suggestion how to improve documentation?
> > Tony, ping. What do you prefer or how do you want to improve this change?
ping
RT-Send-CC: perl5-porters [...] perl.org
On Thu, 28 Mar 2019 05:58:25 -0700, pali@cpan.org wrote: Show quoted text
> On Tuesday 26 February 2019 10:00:58 pali@cpan.org wrote:
> > On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote:
> > > On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > > > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > > > And here is patch which makes sv_mortalcopy_flags() function public.
> > > > > > > > +=for apidoc sv_mortalcopy_flags > > > > + > > > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed to the > > > > +C<sv_setsv_flags>. > > > > + > > > > > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > > > > > So... any suggestion how to improve documentation?
> > > > Tony, ping. What do you prefer or how do you want to improve this change?
> > ping
Sorry, I thought this was all resolved (and I was sort of wrong.) Since sv_mortalcopy_flags()'s treatment of S_GMAGIC is equivalent to sv_setsv_flags() treatment, I no longer think there's any extra documentation needed. I mis-read the code, sorry for my misunderstanding and the delay in the response. Tony
Date: Tue, 2 Apr 2019 11:51:28 +0200
To: perlbug-followup [...] perl.org
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
From: pali [...] cpan.org
Download (untitled) / with headers
text/plain 1.2k
On Thursday 28 March 2019 17:01:47 Tony Cook via RT wrote: Show quoted text
> On Thu, 28 Mar 2019 05:58:25 -0700, pali@cpan.org wrote:
> > On Tuesday 26 February 2019 10:00:58 pali@cpan.org wrote:
> > > On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote:
> > > > On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > > > > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > > > > And here is patch which makes sv_mortalcopy_flags() function public.
> > > > > > > > > > +=for apidoc sv_mortalcopy_flags > > > > > + > > > > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed to the > > > > > +C<sv_setsv_flags>. > > > > > + > > > > > > > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > > > > > > > So... any suggestion how to improve documentation?
> > > > > > Tony, ping. What do you prefer or how do you want to improve this change?
> > > > ping
> > Sorry, I thought this was all resolved (and I was sort of wrong.) > > Since sv_mortalcopy_flags()'s treatment of S_GMAGIC is equivalent to sv_setsv_flags() treatment, I no longer think there's any extra documentation needed. > > I mis-read the code, sorry for my misunderstanding and the delay in the response.
Ok, so are there any other changes needed for this patch?
Subject: Re: [perl #132964] Missing newSVsv_nomg macro variant
From: pali [...] cpan.org
To: perlbug-followup [...] perl.org
Date: Tue, 23 Apr 2019 15:27:20 +0200
Download (untitled) / with headers
text/plain 1.3k
On Tuesday 02 April 2019 11:51:28 pali@cpan.org wrote: Show quoted text
> On Thursday 28 March 2019 17:01:47 Tony Cook via RT wrote:
> > On Thu, 28 Mar 2019 05:58:25 -0700, pali@cpan.org wrote:
> > > On Tuesday 26 February 2019 10:00:58 pali@cpan.org wrote:
> > > > On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote:
> > > > > On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > > > > > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > > > > > And here is patch which makes sv_mortalcopy_flags() function public.
> > > > > > > > > > > > +=for apidoc sv_mortalcopy_flags > > > > > > + > > > > > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed to the > > > > > > +C<sv_setsv_flags>. > > > > > > + > > > > > > > > > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > > > > > > > > > So... any suggestion how to improve documentation?
> > > > > > > > Tony, ping. What do you prefer or how do you want to improve this change?
> > > > > > ping
> > > > Sorry, I thought this was all resolved (and I was sort of wrong.) > > > > Since sv_mortalcopy_flags()'s treatment of S_GMAGIC is equivalent to sv_setsv_flags() treatment, I no longer think there's any extra documentation needed. > > > > I mis-read the code, sorry for my misunderstanding and the delay in the response.
> > Ok, so are there any other changes needed for this patch?
So if not, can you apply that patch?
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Tue, 23 Apr 2019 06:27:36 -0700, pali@cpan.org wrote: Show quoted text
> On Tuesday 02 April 2019 11:51:28 pali@cpan.org wrote:
> > On Thursday 28 March 2019 17:01:47 Tony Cook via RT wrote:
> > > On Thu, 28 Mar 2019 05:58:25 -0700, pali@cpan.org wrote:
> > > > On Tuesday 26 February 2019 10:00:58 pali@cpan.org wrote:
> > > > > On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote:
> > > > > > On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > > > > > > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > > > > > > And here is patch which makes sv_mortalcopy_flags() > > > > > > > > function public.
> > > > > > > > > > > > > > +=for apidoc sv_mortalcopy_flags > > > > > > > + > > > > > > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed > > > > > > > to the > > > > > > > +C<sv_setsv_flags>. > > > > > > > + > > > > > > > > > > > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > > > > > > > > > > > So... any suggestion how to improve documentation?
> > > > > > > > > > Tony, ping. What do you prefer or how do you want to improve > > > > > this change?
> > > > > > > > ping
> > > > > > Sorry, I thought this was all resolved (and I was sort of wrong.) > > > > > > Since sv_mortalcopy_flags()'s treatment of S_GMAGIC is equivalent > > > to sv_setsv_flags() treatment, I no longer think there's any extra > > > documentation needed. > > > > > > I mis-read the code, sorry for my misunderstanding and the delay in > > > the response.
> > > > Ok, so are there any other changes needed for this patch?
> > So if not, can you apply that patch?
https://rt.perl.org/Ticket/Display.html?id=132964#txn-1614862 It was applied. Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Mon, 13 May 2019 17:09:09 -0700, tonyc wrote: Show quoted text
> On Tue, 23 Apr 2019 06:27:36 -0700, pali@cpan.org wrote:
> > On Tuesday 02 April 2019 11:51:28 pali@cpan.org wrote:
> > > On Thursday 28 March 2019 17:01:47 Tony Cook via RT wrote:
> > > > On Thu, 28 Mar 2019 05:58:25 -0700, pali@cpan.org wrote:
> > > > > On Tuesday 26 February 2019 10:00:58 pali@cpan.org wrote:
> > > > > > On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote:
> > > > > > > On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > > > > > > > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > > > > > > > And here is patch which makes sv_mortalcopy_flags() > > > > > > > > > function public.
> > > > > > > > > > > > > > > > +=for apidoc sv_mortalcopy_flags > > > > > > > > + > > > > > > > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed > > > > > > > > to the > > > > > > > > +C<sv_setsv_flags>. > > > > > > > > + > > > > > > > > > > > > > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > > > > > > > > > > > > > So... any suggestion how to improve documentation?
> > > > > > > > > > > > Tony, ping. What do you prefer or how do you want to improve > > > > > > this change?
> > > > > > > > > > ping
> > > > > > > > Sorry, I thought this was all resolved (and I was sort of wrong.) > > > > > > > > Since sv_mortalcopy_flags()'s treatment of S_GMAGIC is equivalent > > > > to sv_setsv_flags() treatment, I no longer think there's any extra > > > > documentation needed. > > > > > > > > I mis-read the code, sorry for my misunderstanding and the delay in > > > > the response.
> > > > > > Ok, so are there any other changes needed for this patch?
> > > > So if not, can you apply that patch?
> > https://rt.perl.org/Ticket/Display.html?id=132964#txn-1614862
Your reply didn't make it to the ticket. You're right, I missed a patch, I'll apply it post 5.31. Tony
RT-Send-CC: perl5-porters [...] perl.org
On Tue, 14 May 2019 17:02:17 -0700, tonyc wrote: Show quoted text
> On Mon, 13 May 2019 17:09:09 -0700, tonyc wrote:
> > On Tue, 23 Apr 2019 06:27:36 -0700, pali@cpan.org wrote:
> > > On Tuesday 02 April 2019 11:51:28 pali@cpan.org wrote:
> > > > On Thursday 28 March 2019 17:01:47 Tony Cook via RT wrote:
> > > > > On Thu, 28 Mar 2019 05:58:25 -0700, pali@cpan.org wrote:
> > > > > > On Tuesday 26 February 2019 10:00:58 pali@cpan.org wrote:
> > > > > > > On Wednesday 13 February 2019 20:16:03 pali@cpan.org wrote:
> > > > > > > > On Tuesday 12 February 2019 20:13:42 Tony Cook via RT wrote:
> > > > > > > > > On Thu, 07 Feb 2019 05:29:14 -0800, pali@cpan.org wrote:
> > > > > > > > > > And here is patch which makes sv_mortalcopy_flags() > > > > > > > > > > function public.
> > > > > > > > > > > > > > > > > > +=for apidoc sv_mortalcopy_flags > > > > > > > > > + > > > > > > > > > +Like C<sv_mortalcopy>, but the extra C<flags> are passed > > > > > > > > > to the > > > > > > > > > +C<sv_setsv_flags>. > > > > > > > > > + > > > > > > > > > > > > > > > > > > SV_GMAGIC is also meaningful for sv_mortalcopy_flags().
> > > > > > > > > > > > > > > > So... any suggestion how to improve documentation?
> > > > > > > > > > > > > > Tony, ping. What do you prefer or how do you want to improve > > > > > > > this change?
> > > > > > > > > > > > ping
> > > > > > > > > > Sorry, I thought this was all resolved (and I was sort of wrong.) > > > > > > > > > > Since sv_mortalcopy_flags()'s treatment of S_GMAGIC is equivalent > > > > > to sv_setsv_flags() treatment, I no longer think there's any extra > > > > > documentation needed. > > > > > > > > > > I mis-read the code, sorry for my misunderstanding and the delay in > > > > > the response.
> > > > > > > > Ok, so are there any other changes needed for this patch?
> > > > > > So if not, can you apply that patch?
> > > > https://rt.perl.org/Ticket/Display.html?id=132964#txn-1614862
> > Your reply didn't make it to the ticket. > > You're right, I missed a patch, I'll apply it post 5.31.
Thanks, applied as c6dcb9ed461718e37907fd4a12e9c4e267d460eb. Sorry for the mix-up. Tony


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org