From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119289 invoked by alias); 2 Nov 2015 11:14:02 -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 119279 invoked by uid 89); 2 Nov 2015 11:14:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Nov 2015 11:14:01 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 9D166A80610; Mon, 2 Nov 2015 12:13:58 +0100 (CET) Date: Mon, 02 Nov 2015 11:14:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Bug in collation functions? Message-ID: <20151102111358.GZ5319@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20151029153516.GJ5319@calimero.vinschen.de> <56323F2E.4030807@cornell.edu> <56324598.9060604@cornell.edu> <56324E82.7000402@redhat.com> <563268A4.6000005@cornell.edu> <56329462.2090206@cornell.edu> <56329BE8.808@cornell.edu> <20151030120320.GO5319@calimero.vinschen.de> <56337996.2000400@cornell.edu> <5634F6BA.7070301@cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZPRTZ4IozCHrMUKG" Content-Disposition: inline In-Reply-To: <5634F6BA.7070301@cornell.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-11/txt/msg00023.txt.bz2 --ZPRTZ4IozCHrMUKG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2860 On Oct 31 13:13, Ken Brown wrote: > On 10/30/2015 10:07 AM, Ken Brown wrote: > >Hi Corinna, > > > >On 10/30/2015 8:03 AM, Corinna Vinschen wrote: > >>On Oct 29 18:21, Ken Brown wrote: > >>>The fallback I had in mind is to return the shorter string if they have > >>>different lengths and otherwise to revert to wcscmp. > > > > >>I had a longer look into this suggestion and the below code and it took > >>me some time to find out what bugged me with it: > >> > >>What about str/wcsxfrm? > >> > >>Per POSIX, calling strcmp on the result of strxfrm is equivalent to > >>calling strcoll (analogue with wcs*). If you extend *coll to perform an > >>extra check on the length, you will have cases in which the above rule > >>fails. You can't perform the length test on the result of *xfrm and > >>expect the same result as in *coll. > >> > >>In fact, when calling LCMapStringW with NORM_IGNORESYMOLS (you would > >>have to do this anyway if we add this flag in *coll), the resulting > >>transformed strings created from the input strings "11" and "1.1" would > >>be identical, so a length test on the xfrm string is not meaningful at > >>all. > >> > >>The bottom line is, afaics, we must make sure that CompareStringW and > >>LCMapStringW are called the same way, and their result/output has to be > >>returned to the caller. Performing an extra check in *coll which can't > >>be reliably performed in *xfrm is not feasible. > >> > >>Does that make sense? > > > >Yes, I see the problem, and I don't see a good way around it. So I > >think we probably have to leave things as they are and live with the > >fact that we can't do comparisons that ignore whitespace and punctuation. > > > >The alternative of allowing str/wcscoll to return 0 on unequal strings > >doesn't seem feasible in view of Eric's comments. >=20 > I have one other idea. What would you think of defining a function > cygwin_strcoll that's like strcoll but with an extra bool parameter > 'ignoresymbols'? If ignoresymbols =3D false, this would be the same as > strcoll. If ignoresymbols =3D true, this would use NORM_IGNORESYMBOLS wi= th > the fallback I suggested. >=20 > That way applications that prefer to be more glibc-compatible and don't n= eed > strxfrm could do something like >=20 > #define strcoll(A,B) cygwin_strcoll ((A), (B), true) >=20 > If you think this is reasonable, I'll submit a patch. If not, no problem. No, I don't think this is feasible. Given Eric's comments, can an application ever expect that strcoll behaves exactly as on Linux? For portability reasons, it has to expect different results on different platforms. Only if the result is POSIXly incorrect, it makes sense to fix the behaviour, IMHO. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --ZPRTZ4IozCHrMUKG Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWN0V2AAoJEPU2Bp2uRE+gJsUP/0eNYlGi6b3sc1K9nBqx8HUT P4X3r6sqQGxDqNi5xGDa2ff57sSWaPt2rsGfJwR1rtEC/tjjPqMT4nBAVeDjMeyU 6JMRcECKHG4U55JMrp0ZxE9EY8Xt+6KScgAztxqa3KRFrkY2v+u82FDV/h1Xn/Kl 8T3o3u5mgBhmkjiXODsMVRpw1EOy0+lxpDxa3ko60kWSnWlde9WwU5w9NpJC6QMs QTprnU/kjdd47crlglDr2qfPTBDUtIP06VrtqyEBQQfbqqEdW9wT2grP4nKLluXV 8mAHq8HGITV7fxszWSoIpMMrgONKj9l/gtUVsywhi3MVixqxYXZ0fHlWKu7cFlH3 a6nEijZ/faBRBH3I4xuBjLvegaVwWCBR9AIGVYd4y1PJ14p/Qq4uIpxcl6S1gdOZ tLDYNOux+Fo1qkQ2FocnT+fyG1wTMP1Kx+8XdS6lwxjZem10DOHcgbEiZ58IrvPA JnCr13x5ED+Hx1BfTy6f7tEpYki/5pWNPZehTK7oAd7QSwll3eAosK7bOZXsC72I SqykTQjrE5BSy9VvHeuiWqcYuaIA8AcVpUzCtMFwN3Zijx/qA0RX/YLzgV839UhU B4c4SwopJvVSV9adciVztgwEccfhij5Mbt3SvLQJj2PlWU6MZJpfHbOgf498cRWx W47+u+Wl91V/CJaduwSX =xFVZ -----END PGP SIGNATURE----- --ZPRTZ4IozCHrMUKG--