[PATCH 1/2] LC_COLLATE: Fix handling of last character in ellipsis, (Bug 22668)
Florian Weimer
fweimer@redhat.com
Mon Jun 29 08:13:24 GMT 2020
* 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:
> <U0010FFFF>
> <U0000FFFF>
> <U000007FF>
> <U0000007F>
> 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 <carlos@redhat.com>
> ---
> 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"),
> }
> }
> }
> + /* Move the cursor to the last entry in the ellipsis.
> + Subsequent operations need to start from the last entry. */
> + collate->cursor = 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 “Enqueue the new
element” cases.
Thanks,
Florian
More information about the Libc-alpha
mailing list