On Fri, Feb 19, 2010 at 14:00, Tim Bunce <Tim.Bunce@pobox.com> wrote:
> On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
>> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker <badalex@gmail.com> wrote:
>> > It seems to me a more correct fix would be to require utf8; inside of
>> > the safe like we do strict.
>> > ....
>> > Id favor this approach as if you have utf8 strings the likely hood
>> > that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8
>> > is fairly high. =C2=A0Then again, no one has complained thus far... =
=C2=A0Maybe
>> > thats just me :)
>>
>> On second thought, I dont think we should import any of those by
>> default. =C2=A0And your hack for just SWASHNEW is better.
Funny.. Safe.pm already does this (share various utf8:: functions) so
I think there should be no question that what you did in the patch
below is correct and a bug with Safe. Sorry for the handwaves, that
was me trying to understand the problem and your fix. :)
> Here's the corresponding perlbug http://rt.perl.org/rt3/Ticket/Display.ht=
ml?id=3D72942
Hrm... Is the require utf8; strictly needed? A reading of perldoc utf8
seems to say the do { my $unicode =3D ... } (aka load utf8_heavy.pl)
part should make it all work fine.
It also seems to still work
t/safeutf8.t ....... ok
*shrug*
> I'll retest 8.4 and 9.0 against this on Monday.
Ill see if I can squeeze in some pg 8.4 perl 5.10.1 linux x86_64
testing tonight of the above. (Ill just reply to the perl bug )
