This is the mail archive of the
mailing list for the Cygwin project.
Re: Bug in collation functions?
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin at cygwin dot com
- Date: Thu, 29 Oct 2015 11:45:50 -0400
- Subject: Re: Bug in collation functions?
- Authentication-results: sourceware.org; auth=none
- References: <563148AF dot 1000502 at cornell dot edu> <5631996D dot 7040908 at redhat dot com> <20151029075050 dot GE5319 at calimero dot vinschen dot de> <20151029083057 dot GH5319 at calimero dot vinschen dot de> <56321815 dot 7000203 at cornell dot edu> <20151029153516 dot GJ5319 at calimero dot vinschen dot de>
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
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
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
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple