[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