[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unexpected behavior with TZ

From: gmail
Subject: Re: Unexpected behavior with TZ
Date: Fri, 08 Apr 2011 00:16:58 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: Gecko/20110303 Thunderbird/3.1.9


06/04/2011 15:18, Chet Ramey :

While looking after the multibyte test, i notice a behavior with
printf3.sub that surprises me.
Apply the patches.  Patch 5 addresses this.


I have applied the eight patches and the test works fine, sorry for the noise.

I have studied a little the multibyte test and noticed that the locales specified with the LANG environment variable are not considered by the glibc's methods mblen and mbtowc (stdlib.h), called from the method asciicode (buitlins/printf.def) when the LC_ALL or LC_CTYPE environment variables are already set.

The multibyte test is successful on my host if i have first unset LC_ALL and LC_CTYPE before running it.

I 'm not fully familiar with POSIX specifications regarding locales, for now these specifications let me think that this behavior is expected and that the LANG environment variable is taken into account after the LC_* environment variables. Therefore, perhaps this could be a way to deal with this issue without (i hope) side effects on other archs :

--- tests/printf2.sub.orig      2009-02-24 20:12:32.000000000 +0100
+++ tests/printf2.sub   2011-04-07 23:21:24.000000000 +0200
@@ -1,4 +1,6 @@
 export LANG=en_US.UTF-8
+unset LC_ALL
+unset LC_CTYPE

 case $(printf %d\\n \'Ã) in
 192)   exit 0;;

On another point, the multibyte documentation on mblen and mbtowc mentions that these two methods maintains an internal shift state (probably a way to be able to operate with bytes streams). I have noticed the DECLARE_MBSTATE macro in the asciicode method and wonder if it is the way to guaranteed a clear initial state to the mblen and mbtowc method. As i see in the docs, a call to mbtowc(NULL, NULL, 0); resets the internal state but this is an overhead that was not required regarding the asciicode method ?

Regards, Cedric.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]