Geoffrey Young wrote: [..]
[...]- 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.
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 you forget that nobody is going pass SVt_PVBM scalar to print(). Why would they? Do you have a concrete example of someone trying to send a scalar of type > PV to print? Rafael, can you think of such an example?
May be to be on the safe side we should check >= SVt_PV and SvPVOK?
but if the change fixes the bug and you're comfortable with it I'll put it in.
Let's do this: try to fix it in the next version. If someone discovers that we broke their code we will revert it. How does it sound?
Ideally, the deprecation cycle goes as follows:that's a bit over-zealous as far as I'm concerned - there's no reason we
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.
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.
It'd be an ill idea to remove features in mp1. If someone who heavily relying on a feature and has to stay with mp1 and needs to use the latter versions, to get some other fixes, you put them in trouble. Sure they "could" go and fix their code, but why should they? To them it'll be you purposely breaking their code.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
