From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45448 invoked by alias); 29 Oct 2015 15:45:53 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 44354 invoked by uid 89); 29 Oct 2015 15:45:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: limerock03.mail.cornell.edu Received: from limerock03.mail.cornell.edu (HELO limerock03.mail.cornell.edu) (128.84.13.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Oct 2015 15:45:51 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id t9TFjjma017992 for ; Thu, 29 Oct 2015 11:45:47 -0400 Received: from [10.13.22.3] (50-192-21-217-static.hfc.comcastbusiness.net [50.192.21.217]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id t9TFjhXJ017216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 29 Oct 2015 11:45:45 -0400 Subject: Re: Bug in collation functions? To: cygwin@cygwin.com References: <563148AF.1000502@cornell.edu> <5631996D.7040908@redhat.com> <20151029075050.GE5319@calimero.vinschen.de> <20151029083057.GH5319@calimero.vinschen.de> <56321815.7000203@cornell.edu> <20151029153516.GJ5319@calimero.vinschen.de> From: Ken Brown Message-ID: <56323F2E.4030807@cornell.edu> Date: Thu, 29 Oct 2015 16:14:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151029153516.GJ5319@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00538.txt.bz2 On 10/29/2015 11:35 AM, Corinna Vinschen wrote: > On Oct 29 08:59, Ken Brown wrote: >> On 10/29/2015 4:30 AM, Corinna Vinschen wrote: >>> On Oct 29 08:50, Corinna Vinschen wrote: >>>> On Oct 28 21:58, Eric Blake wrote: >>>>> On 10/28/2015 04:14 PM, Ken Brown wrote: >>>>>> It's my understanding that collation is supposed to take whitespace and >>>>>> punctuation into account in the POSIX locale but not in other locales. >>>>> >>>>> Not quite right. It is up to the locale definition whether whitespace >>>>> affects collation. But you are correct that in the POSIX locale, >>>>> whitespace must not be ignored in collation. >>>>> >>>>>> This doesn't seem to be the case on Cygwin. Here's a test case using >>>>>> wcscoll, but the same problem occurs with strcoll. >>>>> >>>>> That's because the locale definitions are different in cygwin than they >>>>> are in glibc. But it is not a bug in Cygwin; POSIX allows for different >>>>> systems to have different locale definitions while still using the same >>>>> locale name like en_US.UTF-8. >>>> >>>> Btw, strcoll and wcscoll in Cygwin are implemented using the Windows >>>> function CompareStringW with the LCID set to the locale matching the >>>> POSIX locale setting. I'm rather glad I didn't have to implement this >>>> by myself... :} >>> >>> OTOH, CompareString has a couple of flags to control its behaviour, see >>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx >>> >>> Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there >>> are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS. I'm open to a >>> discussion how to change the settings to more closely resemble the rules >>> on Linux. >>> >>> E.g. wcscoll simply calls wcscmp rather than CompareStringW for the >>> C/POSIX locale anyway. So, would it makes sense to set the flags to >>> NORM_IGNORESYMBOLS in other locales? >> >> I think so. That's what the native Windows build of emacs does in this >> situation. > > Is that all it's doing? I'm asking because using NORM_IGNORESYMBOLS > does not exaclty resemble the behaviour on Linux on my W10 box: > > "11" > "1.1" in POSIX locale > !!! "11" > "1.1" in en_US.UTF-8 locale > "11" > "1 2" in POSIX locale > "11" < "1 2" in en_US.UTF-8 locale I just noticed that myself and was going to ask about that difference. I don't see anything else that emacs is doing on native Windows. But in the test I referred to above, the locale is set to "enu_USA" in the native Windows build. Does that explain the discrepancy? If not, I can ask on the emacs-devel list whether the test passes on Windows. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple