From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3BBC21F9FD for ; Mon, 1 Mar 2021 17:17:16 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DA57E3939C37; Mon, 1 Mar 2021 17:17:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA57E3939C37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1614619034; bh=rhfMdsrrNrn1/y8ykr5BzYLdHmze2r96H+QVDz9bGFg=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=V9KNVMpHLCkUH9OhBMY+MYh1GmTBJB1coAJioFdLoJU8Lc7Yk+/TBawjzjfaZlMy1 Kzt99+nv1m0Ps7QWUAVRiwMpweETi9LmNCQgNbx2B1KS+neIE9Gq1Md9CxWoCORcIq RVVVx3Ps4qp31K3xs/3Xj2lH48Dx+lhNSt3/W0hM= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 7B00F385482D for ; Mon, 1 Mar 2021 17:17:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7B00F385482D 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-574-uziIIdYvOT6cVthN2ev8Zw-1; Mon, 01 Mar 2021 12:17:10 -0500 X-MC-Unique: uziIIdYvOT6cVthN2ev8Zw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 74A7B107ACE3; Mon, 1 Mar 2021 17:17:09 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-131.ams2.redhat.com [10.36.113.131]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4662310016DB; Mon, 1 Mar 2021 17:17:05 +0000 (UTC) To: Carlos O'Donell via Libc-alpha Subject: Re: [PATCH] LC_COLLATE: Fix last character ellipsis handling (Bug 22668) References: <20210218050217.2128682-1-carlos@redhat.com> Date: Mon, 01 Mar 2021 18:18:01 +0100 In-Reply-To: <20210218050217.2128682-1-carlos@redhat.com> (Carlos O'Donell via Libc-alpha's message of "Thu, 18 Feb 2021 00:02:17 -0500") Message-ID: <87pn0idc8m.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: Hanataka Shinya Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * Carlos O'Donell via Libc-alpha: > From: Hanataka Shinya > > During ellipsis processing the collation cursor was not correctly > moved to the end of the ellipsis after processing. > > The code inserted the new entry after the cursor, but before the > real end of the ellipsis: > [cursor] > ... element_t <-> element_t <-> element_t <-> element_t > "" "" "" > startp endp > > At the end of the function we have: > > [cursor] > ... element_t <-> element_t <-> element_t > "" "" > endp > > The cursor should be pointing at endp, the last element in the > doubly-linked list, otherwise when execution returns to the > caller we will start inserting the next line after . > > 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 0af21e05e2..b6406b775d 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"), > } > } > } > + /* Move the cursor to the last entry in the ellipsis. > + Subsequent operations need to start from the last entry. */ > + collate->cursor = endp; > } I do not completely understand the code, but I double-checked a few things, and this looks consistent. So I guess it's okay to check this in. Thanks, Florian