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-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 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 [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 126561F8C6 for ; Wed, 18 Aug 2021 08:13:10 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 83D79388980C for ; Wed, 18 Aug 2021 08:13:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83D79388980C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629274388; bh=IA5Tb2azQ9zdBZteSZtZkHUxNdFTGSgkxz+F/tlMuhI=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=mm6nwcX6MJwTK2YNqok1AOSOOtidr6hVdxt7cGCZ2BT+E92tIa8jRCsvIXQOmOlh5 X3/2SjPD4qUDpwN4RcCBm5s80hbZCNdftGZMaCOI8f7rEuavfGYA0QOj8vvST+rErx HDrNSiYWj1J5Ha4fqqs2WwumbwHDasSDylnw+3ao= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 66DC33889404 for ; Wed, 18 Aug 2021 08:12:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 66DC33889404 Date: Wed, 18 Aug 2021 04:12:43 -0400 To: Florian Weimer Subject: Re: [PATCH v4 0/3] C.UTF-8 Message-ID: Mail-Followup-To: Florian Weimer , Carlos O'Donell via Libc-alpha References: <20210729063515.1541388-1-carlos@redhat.com> <87bl6l5zeb.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87bl6l5zeb.fsf@oldenburg.str.redhat.com> 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: Mike Frysinger via Libc-alpha Reply-To: Mike Frysinger Cc: Carlos O'Donell via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 29 Jul 2021 09:53, Florian Weimer via Libc-alpha wrote: > * Carlos O'Donell via Libc-alpha: > > The following changes implement a minimally sized C.UTF-8. > > First we implement the 'strcmp_collation' directive. > > Then we implement C.UTF-8 with an LC_COLLATE that uses the > > 'strcmp_collation' directive to support using strcmp for > > collation i.e. code point sorting. The final C.UTF-8 is > > only ~396KiB with the largest ~346KiB in LC_CTYPE for all > > of Unicode. > > > > This v4 fixes the regressions detected in Fedora Rawhide > > here: https://bugzilla.redhat.com/show_bug.cgi?id=1986421 > > Additional testing coverage is provided for fnmatch, regcomp, > > and regexec (which would have caught the regression). > > From a high-level point of view I wonder if the more conservative choice > would be to fix the localdef generation for LC_COLLATE, at least for > this release. It would also mean that we do not break statically linked > executables. glibc already (somewhat regularly) breaks statically linked programs due to nss incompatibilities. unless/until we take that seriously, i'm not sure we should bother expending effort on these trade-offs. just go with whatever makes sense long term. -mike