From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 845D63944803 for ; Mon, 26 Apr 2021 12:39:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 845D63944803 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-375-td78_hapNXySBJatC3S7Gw-1; Mon, 26 Apr 2021 08:39:53 -0400 X-MC-Unique: td78_hapNXySBJatC3S7Gw-1 Received: by mail-qk1-f200.google.com with SMTP id t77-20020a37aa500000b02902e49d708227so1819088qke.23 for ; Mon, 26 Apr 2021 05:39:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=QvmXTaUJpo9tV8njWlmTA2/0qzwtNutkkKGZK8wYAwk=; b=XlqPYXYGOl3SurtqEtKPKGPc4JdGA8aRkINopc6fVgQzbGcIhbaXC0lPezGmXtczXH auYsfxgde1rESOgm9UmSpYyUabRMHF0zhCgX5gocVMTs5ezQc4KtYkAp8+e1eaRAH4QA 6q/hkeotV4Di/YobQ8ZG4dZgmu3+j4eKPJ4k4KXO0SDwG2io9y4huIqsV47L4maw2BvT 9hdPZPm4X5XEel5miEW7GeOSLuS1s7wuke4txrjeLkVhsLB9kTYOPA1e/kddiiuKBb7b IzueBx30NeLZDYUgCLb4RkD3lyoe+NaCSwwTvtLhALMY/LLY85XOtziGo/qm+kX4//dq k2xA== X-Gm-Message-State: AOAM533Se26ZL/pqgkxWRAsq6ZBIqXH2ni8me8Gc5G9+xD6u2SXPE6Ie ufEi0zwYth8FYUK0lCnxuTLn9/j4yC4s8E852Psf0/y6DV3TwqKDNRauDuAT0n4IIAJjvUCZYL8 BLtxV6Slsox3EhZSHevOa X-Received: by 2002:a0c:eb06:: with SMTP id j6mr17437642qvp.10.1619440793127; Mon, 26 Apr 2021 05:39:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZp3t4BodXlyaRnRtxrmW77yqOKtG89LqcAJJtsdbPTJ2c2TrlruO69Pu+sSIhrsiqdxBOvQ== X-Received: by 2002:a0c:eb06:: with SMTP id j6mr17437630qvp.10.1619440792948; Mon, 26 Apr 2021 05:39:52 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id n11sm11247982qkn.33.2021.04.26.05.39.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Apr 2021 05:39:52 -0700 (PDT) Subject: Re: [PATCH] LC_COLLATE: Fix last character ellipsis handling (Bug 22668) To: Florian Weimer , Carlos O'Donell via Libc-alpha Cc: Hanataka Shinya References: <20210218050217.2128682-1-carlos@redhat.com> <87pn0idc8m.fsf@oldenburg.str.redhat.com> From: Carlos O'Donell Organization: Red Hat Message-ID: <7bb98c19-b0bc-7565-1974-73bf69a69393@redhat.com> Date: Mon, 26 Apr 2021 08:39:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87pn0idc8m.fsf@oldenburg.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, 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, 26 Apr 2021 12:39:56 -0000 On 3/1/21 12:18 PM, Florian Weimer wrote: > * 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. Re-tested again, no regressions. Pushed. Thanks. -- Cheers, Carlos.