DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; q=dns; s=default; b=po2R
	m8L6609Hzf6W7uZAKRlBwOSCj1hGwE9HHwGm8uwQm9x7AFE8murD76ghuzDK2d7N
	DywNKNhmPHFMZbcSmzC2pFWQMwX1GYyWYHDAHYHzqNTc8BY10aTUQ54hDz7gmLY1
	HD71jvZIKDFaLWYck7oy5FVCghuqLMsMhZetcoM=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
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> <56323F2E.4030807@cornell.edu> <56324598.9060604@cornell.edu>
From: Eric Blake <eblake@redhat.com>
Openpgp: url=http://people.redhat.com/eblake/eblake.gpg
Message-ID: <56324E82.7000402@redhat.com>
Date: Thu, 29 Oct 2015 10:51:14 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56324598.9060604@cornell.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s83N2AxduQmHUw7jsbejrVtfRvSc9FMXV"

--s83N2AxduQmHUw7jsbejrVtfRvSc9FMXV
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/29/2015 10:13 AM, Ken Brown wrote:

> Never mind.  My test case was flawed, because it didn't check for the
> possibility that wcscoll might return 0.  Here's a revised definition of
> the "compare" function:
>=20
> void
> compare (const wchar_t *a, const wchar_t *b, const char *loc)
> {
>   setlocale (LC_COLLATE, loc);
>   int res =3D wcscoll (a, b);
>   char c =3D res < 0 ? '<' : res > 0 ? '>' : '=3D';
>   printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc);
> }
>=20
> With this change (and the use of NORM_IGNORESYMBOLS) the test returns
> the following on Cygwin:
>=20
> $ ./wcscoll_test
> "11" > "1.1" in POSIX locale
> "11" =3D "1.1" in en_US.UTF-8 locale
> "11" > "1 2" in POSIX locale
> "11" < "1 2" in en_US.UTF-8 locale
>=20
> It still differs from Linux, but it's good enough to make the emacs test
> pass.  Moreover, this behavior actually seems more reasonable to me than
> the Linux behavior.  After all, if you're ignoring punctuation, how can
> you decide which of "11" or "1.1" comes first?

Careful.  POSIX is proposing some wording that say that normal locales
should always implement a fallback of last resort (and that locales that
do not do so should have a special name including '@', to make it
obvious).  It is not standardized yet, but worth thinking about.

http://austingroupbugs.net/view.php?id=3D938
http://austingroupbugs.net/view.php?id=3D963

The intent of that wording is that if ignoring punctuation could cause
two strings to otherwise compare equal, the fallback of a total ordering
on all characters means that the final result of strcoll() will not be 0
unless the two strings are identical.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--s83N2AxduQmHUw7jsbejrVtfRvSc9FMXV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJWMk6CAAoJEKeha0olJ0NqVuYIAI8WaHqWAhm2xTsfGxl2XqoQ
+sK4w7fgNDXOmuhD/CNmXk1MK6Vd0VTm5/mUIGsRFzvZz/y+HLeELD8GuEt45kT4
fse/ku4A4c8uZz7K6i2nHTZQ1gGd4/3zhEvBAnTe6tKLDWBcO8YgN/7ak0kEY0jV
+rqBQbb5QItfLJQbWT735nqd0JW3WqOJPrGhxSrnliYrE4BlvEFSm0cV2n1EoYoc
1T1bpQxSjKRVxqOy+Cu5mIiavD0DiBQsTdUFBW7MMOUe45NuSnbqaLepj8L6ygO7
oi7h8Dag4OzES1BVWKoRr3zz0MrXrCsK0hGqia3VjBCSph0Zbm+isYdbG5R/Hx8=
=Bg5x
-----END PGP SIGNATURE-----

--s83N2AxduQmHUw7jsbejrVtfRvSc9FMXV--