Stas Bekman wrote: > Rafael Garcia-Suarez suggested to: > > - SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV); > + SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV); > > +1 to fix this bug. > > Jonathan, have you verified that it fixes your problem? > > Geoffrey Young then said: > >> but do you really want to derefernce a SVt_PVFM? the implications > here are >> far beyond my reach. > > formats don't work with mod_perl anyway, unless you use SFIO. So it's > probably irrelevant. > http://perl.apache.org/docs/1.0/guide/porting.html#Using_format___and_write__
format was just an example - using the above will dereference everything from SVt_PVBM to SVt_PVIO. it just sounds like an awful lot of stuff to me to be adding where we weren't before (11 more PV variants, according to the crack-pipe book), which drastically increases our exposure to unknown behaviors. but if the change fixes the bug and you're comfortable with it I'll put it in. > Ideally, the deprecation cycle goes as follows: > > 1) leave the current generation of the product as is. > 2) deprecate the feauture in the next generation. > 3) remove it only in the 3rd generation. that's a bit over-zealous as far as I'm concerned - there's no reason we couldn't phase out the feature in the 1.0 tree over time. but with 2.0 reaching fruition, I see no reason to remove any features from 1.0, as the migration to 2.0 will be painful enough without a series of mini-migrations along the way. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
