This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
fix multi-evals problems in pad name list api
authorDaniel Dragan <bulk88@hotmail.com>
Wed, 11 Jun 2014 23:19:17 +0000 (19:19 -0400)
committerTony Cook <tony@develop-help.com>
Tue, 24 Jun 2014 06:35:01 +0000 (16:35 +1000)
commit3769e90dda135d412f0de89530b685b707a22023
treec4b2d63b30d1259d0e5fd0cb5abfe9046d395f11
parentddeaf6457db7d0d56f0cc5a6452effef1d1a0f2f
fix multi-evals problems in pad name list api

The PAD_COMPNAME api, created in dd2155a49b , originally had alot of,
multi-eval problems, since av_fetch would be repeatedly called in macro
expansions. Later in commit b21dc0313d , an incomplete attempt at removing
multi-eval was done. Also in commit 035dab7448 added more multi-eval
problems. Prior to commit dd2155a49b , the code used a seemingly random
mix of av_fetch and AvARRAY, so both are ok. To fix this, replace av_fetch
with func-free AvARRAY. Since existing code has lval 0 to av_fetch and
unconditional deref on ret, a segv is fine to detect breakage.

A #define PAD_COMPNAME_SV(po) \
((assert(!SvMAGICAL(PL_comppad_name))),(AvARRAY(PL_comppad_name)[(po)]))
shows the AV is ! magical/tied during smoke. The assert was not added for
perf reasons on debugging builds. Inline funcs were not used for better
compiler optimizing if PAD_COMPNAME_FLAGS_isOUR is immediatly
followed by PAD_COMPNAME_OURSTASH (2 statements), as in scan_inputsymbol.
Inlines are not guaranteed to be inlined all the time on all compilers in all
situations, Visual C especially. Also inline is more likely to cause readding of
multi-eval problems than the macro if future changes to the API put the inline
func in a multi-eval macro.

On VC 2003 32bit .text section of perl521.dll dropped from 0xC296F to
0xC281F bytes of machine code with this patch.
op.c
pad.c
pad.h