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=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B5B5E1F4B4 for ; Wed, 13 Jan 2021 23:37:06 +0000 (UTC) Received: from localhost ([::1]:46602 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzphJ-0002Lt-FU for normalperson@yhbt.net; Wed, 13 Jan 2021 18:37:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzphD-0002Lb-Ap for bug-gnulib@gnu.org; Wed, 13 Jan 2021 18:36:59 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.23]:18168) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzphB-00073u-6v for bug-gnulib@gnu.org; Wed, 13 Jan 2021 18:36:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610581013; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:From: Subject:Sender; bh=Z7mVVpKBqBQ154HZaGXkKvlV0WlzLW2sV/M4+gcL6JQ=; b=phhScedHKu5U1Z6eWn5nFbI7z7gb5FYeo3XMgd+t3v/OR4kBZTF7xz0ttmcjizG9L3 tukNX4uXTR9gG/OfKm0cCyQ2cjq6mIhOlkh1NvZpRze6gw4vq1FoFj4HdV+JuVq8T+R7 T7LDLLhaRjMR2aHTVlpXsMM21BEeRVg3s7SDWZWlSCQLluF1bxZOF1bRceiRxQQH/mi1 XdLRS6jEh5Fn5hvx6E9kTo2lowIUAGvbqRiQOiDjGUuIwBVzP8U7d8k3NwcMWze1/c18 YO006NYEQkRRBsnbglsBD+CpL7etlK0HPjESogx46EHL7ny1CmLsYpl3aK2rYPVE7AMf aIfg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqfyyvs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id u0aa20x0DNabauW (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Thu, 14 Jan 2021 00:36:37 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: [PATCH 1/2] posix: User scratch_buffer on fnmatch Date: Thu, 14 Jan 2021 00:36:31 +0100 Message-ID: <6269852.OAlbKWrXbI@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <87turkaaot.fsf@oldenburg2.str.redhat.com> References: <20210104202528.1228255-1-adhemerval.zanella@linaro.org> <87turkaaot.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.23; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , Paul Eggert , libc-alpha@sourceware.org, Adhemerval Zanella Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Paul Eggert asked: > > By the way, how important is it to support awful encodings like > > shift-JIS that contain bytes that look like '\'? If we don't have to > > support these encodings any more, things get a bit easier. Here we are talking about locale encodings, and Shift_JIS (as well as SHIFT_JISX0213) are not usable as a locale encoding in glibc. See e.g. [1], [2]. That's the reason why no Shift_JIS locale is listed in glibc/localedata/SUPPORTED. [3] Florian Weimer wrote: > There is a Shift-JIS variant which is ASCII-transparent (Windows-31J, > it's also specified by WhatWG/HTML5), so from a glibc point of view, it > would be just an ordinary charset like any other. > > But feedback we have received is that the users who want Shift-JIS > really want the original thing. > > We do not presently support either variant downstream, but one potential > way forward would be to turn Windows-31J into a fully supported glibc > charset with a corresponding ja_JP locale (which would imply downstream > support as well), and just hope that it displaces the original Shift-JIS > in the future. I don't think there's a real need for that. In the years 1995 ... 2005 there was a lot of resistence against Unicode in Japan, because Unicode maps several slightly differently looking glyph images to the same glyph/character (even for Western encodings, for example the Polish accents look a bit different than the French ones), and - at the time - Unicode did not have means to disambiguate these, thus people complained about "characters are rendered incorrectly if you use Unicode". This has been resolved for more than 10 years already. Bruno [1] https://sourceware.org/bugzilla/show_bug.cgi?id=3140 [2] https://sourceware.org/legacy-ml/libc-alpha/2000-10/msg00311.html [3] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/SUPPORTED