X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 19 Mar 2009 21:11:44 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Q: Is anybody here using the CYGWIN=codepage:oem setting?
Message-ID: <20090319201144.GE9322@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20090319130909 DOT GZ9322 AT calimero DOT vinschen DOT de> <49C281F7 DOT 6080602 AT acm DOT org> <20090319181323 DOT GB1868 AT calimero DOT vinschen DOT de> <49C29366 DOT 8080708 AT acm DOT org> <20090319192031 DOT GB9322 AT calimero DOT vinschen DOT de> <20090319192229 DOT GC9322 AT calimero DOT vinschen DOT de> <loom DOT 20090319T193406-675 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20090319T193406-675@post.gmane.org>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Mar 19 19:41, Eric Blake wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > ...unless Cygwin itself would call setlocale().
> 
> I'm not a fan of that.  POSIX is explicit that an application that 
> intentionally avoids calling setlocale() shall behave as though it had called 
> setlocale(LC_ALL,"C").  If cygwin called setlocale(LC_ALL,"") on applications' 
> behalf, then this will break POSIX-compliance of existing programs.  Not all 
> programs are internationalized yet.  For example, I know that m4 does NOT call 
> setlocale.  On the other hand, I also have no idea how (or even if) m4 would 
> break if cygwin called setlocale on its behalf; about the only functions it 
> calls at the moment where running in a locale besides C would have an impact 
> would be in things like calls to strtod() (not likely to affect many users).  

Newlib's strtod is not exactly locale aware either, right now.  It has
some sort of support for a decimalpoint other than '.', but it doesn't
work correctly given that the replacement character must be a singlebyte
char.  And, there isn't even a function to set the localeconv data to
something different than the default C locale values.

Which is to say, even m4 shouldn't suffer from calling setlocale.

But I admit that I'm not very happy with this idea either.  Still, we
have to convert from MB to WC and vice-versa independently of the
application, while other systems based on byte charsets simply don't
have this problem.

> And one of my goals, as upstream m4 maintainer, is to eventually get m4 to the 
> same state as coreutils where gettext is used to provide translated messages.
> 
> I guess I'm declaring that I have no idea what the best approach would be, but 
> I would like for locales to work without having to worry about changing $CYGWIN.

I don't understand what you're trying to say here.  I would change
Cygwin a lot if we could get full locale support in turn.  Maybe you
were just talking about the setlocale call?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/