On Mon, 3 Dec 2007, Martin Koegler wrote:
> On Mon, Dec 03, 2007 at 04:06:48AM -0800, Jakub Narebski wrote:
>> Ismail Dönmez <[EMAIL PROTECTED]> writes:
>>> Monday 03 December 2007 Tarihinde 12:14:43 yazm??t?:
>>>> Benjamin Close <[EMAIL PROTECTED]> writes:
>>>>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
>>>>> - if (defined $res) {
>>>>> - return $res;
>>>>> - } else {
>>>>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>> - }
>>>>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
>>>>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>> }
>
> This version is broken on Debian sarge and etch. Feeding a UTF-8 and a latin1
> encoding of the same character sequence yields to different results.
[...]
> eval { $res = decode_utf8(...); }
> if ($@)
> return decode(...);
> return $res
>
> or
>
> eval { $res = decode_utf8(...); }
> if (defined $res)
> return $res;
> else
> return decode(...);
>
> show the same (wrong) behaviour on Debian sarge. They do not always
> decode non UTF-8 characters correctly, eg.
> #öäü does not work
> #äöüä does work
>
> On Debian etch, both versions are working.
I don't know enough Perl to decide if it is a bug in gitweb usage
of decode_utf8, if it is a bug in your version of Encode, or if it
is bug in Encode.
Send copy of this mail to maintainers of Encode perl module.
--
Jakub Narebski
Poland
