From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id B0C7A3870867 for ; Mon, 29 Jun 2020 09:40:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B0C7A3870867 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-489-hDNuRAqHOwaC3qgsEuIniQ-1; Mon, 29 Jun 2020 04:13:30 -0400 X-MC-Unique: hDNuRAqHOwaC3qgsEuIniQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 73C50107ACF4; Mon, 29 Jun 2020 08:13:29 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-196.ams2.redhat.com [10.36.112.196]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9DD84121A56; Mon, 29 Jun 2020 08:13:25 +0000 (UTC) From: Florian Weimer To: Carlos O'Donell via Libc-alpha Cc: Hanataka Shinya , Carlos O'Donell Subject: Re: [PATCH 1/2] LC_COLLATE: Fix handling of last character in ellipsis, (Bug 22668) References: <75d21bd8-2698-2e25-969c-4e086c90abd9@redhat.com> Date: Mon, 29 Jun 2020 10:13:24 +0200 In-Reply-To: (Carlos O'Donell via Libc-alpha's message of "Mon, 29 Jun 2020 00:08:21 -0400") Message-ID: <87ftae2st7.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 09:40:16 -0000 * Carlos O'Donell via Libc-alpha: > During ellipsis processing the collation cursor was not correctly > moved to the end of the ellipsis after processing. This meant that > the cursor was left, usually, at the second to last entry. > Subsequent operations end up unlinking the ellipsis end entry or > just leaving it in the list dangling from the end. This kind of > dangling is immediately visible in C.UTF-8 with the following > sorting from strcoll: > > > > > With the cursor correctly adjusted the end entry is correctly given > the right location and thus the right weight. > > No regressions on x86_64 and i686. > > Co-authored-by: Carlos O'Donell > --- > locale/programs/ld-collate.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/locale/programs/ld-collate.c b/locale/programs/ld-collate.c > index feb1a11258..a8ba2f07f0 100644 > --- a/locale/programs/ld-collate.c > +++ b/locale/programs/ld-collate.c > @@ -1483,6 +1483,9 @@ order for `%.*s' already defined at %s:%Zu"), > =09 } > =09} > } > + /* Move the cursor to the last entry in the ellipsis. > + Subsequent operations need to start from the last entry. */ > + collate->cursor =3D endp; > } Can't endp be NULL at this point? Besides that, why does the change make a difference at all? There already is an assignment to collate->cursor in both =E2=80=9CEnqueue the ne= w element=E2=80=9D cases. Thanks, Florian