This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: "C" UTF-8 trouble
On Oct 7 06:03, Eric Blake wrote:
> According to Corinna Vinschen on 10/7/2009 3:03 AM:
> >> Unfortunately that's not the case for emacs.
> >
> > As for Emacs, I'm wondering if it shouldn't be changed to set its locale
> > according to setlocale(LC_CTYPE,NULL) instead, given what POSIX says.
>
> Yes, we should raise this as an upstream bug in emacs.
>
> > Urgh. So we have to change nl_langinfo in newlib as well. Do we have
> > to return "US-ASCII" if charset is "ASCII", or is it sufficient to
> > return __locale_charset() as you did, thus returning "ASCII" for "ASCII"?
>
> Gettext ships (well, used to ship, until recently disabling it for cygwin
> 1.5 because of lacking locale support) a charset.alias file, which mapped
> arbitrary nl_langinfo(CODESET) values into canonical forms.
Isn't that file generated system-dependent, and isn't that file empty
on Cygwin by default?
If so, we can start to fill that file right here. Whatever Cygwin/newlib
returns in nl_langinfo (given we changed it) is correct for charset.alias
as well.
> POSIX does say that the default is implementation-defined, so we have at
> least a chance of convincing newlib that we need a hook to let us do our
> implementation definition (whether it be by file or otherwise).
I take this as a vote for the newlib change.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat