Closed p5pRT closed 11 years ago
See attached patch.
On Thu Nov 22 20:48:59 2012\, bulk88 wrote:
See attached patch.
No response. Ill close it myself.
applied as eed484f95050ad51c720521f68c6341a14bf5638
-- bulk88 ~ bulk88 at hotmail.com
@bulk88 - Status changed from 'new' to 'resolved'
On Thu Nov 22 20:48:59 2012\, bulk88 wrote:
See attached patch.
Thank you. Applied as eed484f95.
I received no responses to http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg195724.html explaining when the SV is replaced in PL_errgv\,
I didnāt answer because I didnāt know whether there are things to worry about other than the obvious $@=... and *@=... assignment that can occur when calling perl code.
so took a conservative view and assumed callbacks (with Perl stack/ENTER/LEAVE/eval_*/call_*) can change it.
Thatās what I would do\, too.
I also assume ERRSV will never return null\, this allows a more efficiently version of SvTRUE to be used.
In Perl_newATTRSUB_flags a wasteful copy to C stack operation with the string was removed\, and a croak_notcontext to remove push instructions to the stack. I was not sure about the interaction between ERRSV and message sv\, I didn't change it to a more efficient (instruction wise\, speed\, idk) format string combining of the not safe string and ERRSV in the croak call. If such an optimization is done\, a compiler potentially will put the not safe string on the first\, unconditionally\, then check PL_in_eval\, and then jump to the croak call site\, or eval ERRSV\, push the SV on the C stack then push the format string "%"SVf"%s". The C stack allocated const char array came from commit e1ec3a884f .
In Perl_eval_pv\, croak_on_error was checked first to not eval ERRSV unless necessery. I was not sure about the side effects of using a more efficient croak_sv instead of Perl_croak (null chars\, utf8\, etc) so I left a comment.
Using croak_sv would probably actually fix bugs in those cases\, but it would need to be examined more carefully first. I mean I canāt tell you off the top of my head whether it would be a safe substitute.
In the future\, a SvEMPTYSTRING macro should be considered (not fully thought out by me) to replace the SvTRUEs with something smaller and faster when dealing with ERRSV.
$@ can be set to something other than a string easily enough. Iām not sure that would be feasible.
--
Father Chrysostomos
On Fri Nov 23 17:58:59 2012\, sprout wrote:
On Thu Nov 22 20:48:59 2012\, bulk88 wrote:
I was not sure about the side effects of using a more efficient croak_sv instead of Perl_croak (null chars\, utf8\, etc) so I left a comment.
Using croak_sv would probably actually fix bugs in those cases\, but it would need to be examined more carefully first. I mean I canāt tell you off the top of my head whether it would be a safe substitute.
The change would probably be script level visible somehow. I guess suddenly blessed and magic and utf8 tieds and all kinds of other things could get through the eval to the caller\, and possibly die in the caller outside the eval when the caller reads $@ or something.
In the future\, a SvEMPTYSTRING macro should be considered (not fully thought out by me) to replace the SvTRUEs with something smaller and faster when dealing with ERRSV.
$@ can be set to something other than a string easily enough. Iām not sure that would be feasible.
In some places SvTRUEs are done to check whether to restore a copy of the original ERRSV back to ERRSV or to execute "we had an exception" branches (eval_pv for example). The problem is\, the strict definition of "we had no exception" is POK\, CUR=0\, non NULL PV with pv[0] == '\0'\, in ERRSV\, according to perlvar. So technically undef\, and IV 0 and NV 0 and PV CUR 1\, p[0] == '0' are all "we had an exception" ("failed() if defined($@) && $@ ne '';") \, yet are treated as "we didnt have an exception". Is that a bug or a feature?
A SvEMPTYSTRING would just check POK and CUR==0 and be done (I'm not sure whether to call magic or not)\, not check IV and NV and string "0". -- bulk88 ~ bulk88 at hotmail.com
Migrated from rt.perl.org#115884 (status was 'resolved')
Searchable as RT115884$