Re: Unexpected behavior with TZ

[gmail]

Hello,

06/04/2011 15:18, Chet Ramey :
> > Hello,
> >
> > While looking after the multibyte test, i notice a behavior with
> > printf3.sub that surprises me.
> Apply the patches.  Patch 5 addresses this.
>
> Chet

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.