Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
sort fns: simplify handing uninit warnings
When a sort function or code block returns an undef value (rather than the typical -1,0,-1), you get the usual "Use of uninitialized value" warning. Originally the message didn't say " ... in sort" because at the end of running a sort sub, PL_op is NULL rather rather than pointing at the sort op. v5.15.3-364-gd4c6760 changed the sort sub return code in S_sortcv() et al to temporarily set PL_op to point to the sort OP, which made Perl_report_uninit() emit the desired " in sort" suffix. However, this meant that PL_op and PL_curpad briefly referenced two different CVs; since Perl_report_uninit() rummages around in pads looking for lexicals, consts etc, this could lead to SEGVs. v5.15.3-372-g1aa032b fixed that by temporarily setting PL_curpad to NULL at the same time. However that then caused problems if the code dies (e.g. if warnings are upgraded to errors) since the old PL_curpad value wasn't being restored. v5.17.6-7-g2f43ddf fixed that by wrapping the PL_curpad=NULL with appropriate ENTER/SAVEVPTR(PL_curpad)/..../LEAVE where necessary. However, this is starting to get quite complex, and in a hot piece of code, and the 3 sort functions S_sortcv/S_sortcv_stacked/S_sortcv_xsub are all diverging from each other in subtle and confusing ways. This commit takes a different approach. It effectively reverts those three commits (apart from the tests) and instead updates Perl_report_uninit() to say "if PL_op is NULL, but the context stack indicates that we're currently in a sort, then append " in sort" to the warning. This is a lot less messy, and moves all the clutter from the two hot functions S_sortcv/S_sortcv_stacked into a function that is only called when we're emitting warnings.
- Loading branch information