This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]