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.0.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4451B1F405 for ; Fri, 21 Dec 2018 00:39:59 +0000 (UTC) Received: from localhost ([::1]:41673 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ga8r8-00005R-Cs for normalperson@yhbt.net; Thu, 20 Dec 2018 19:39:58 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ga8os-0006KE-R7 for bug-gnulib@gnu.org; Thu, 20 Dec 2018 19:37:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ga8oq-000818-PQ for bug-gnulib@gnu.org; Thu, 20 Dec 2018 19:37:38 -0500 Received: from scc-mailout-kit-01.scc.kit.edu ([2a00:1398:9:f712::810d:e751]:58075) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ga8op-0007MY-F3 for bug-gnulib@gnu.org; Thu, 20 Dec 2018 19:37:35 -0500 Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1ga8oR-0004M2-Lr; Fri, 21 Dec 2018 01:37:12 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1ga8oR-0001lD-7w; Fri, 21 Dec 2018 01:37:11 +0100 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1ga8oR-00026c-4A; Fri, 21 Dec 2018 01:37:11 +0100 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id c77c2d62; Fri, 21 Dec 2018 01:37:11 +0100 (CET) Date: Fri, 21 Dec 2018 01:37:11 +0100 From: Ingo Schwarze To: Bruno Haible Subject: Re: OpenBSD locale system Message-ID: <20181221003711.GG13936@athene.usta.de> References: <7256199.52JTtAUSKG@omega> <45443746.orUszaOq50@omega> <20181216231616.GM90457@athene.usta.de> <24927783.nA5Ygb86Ty@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24927783.nA5Ygb86Ty@omega> User-Agent: Mutt/1.8.0 (2017-02-23) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1398:9:f712::810d:e751 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Bruno, Bruno Haible wrote on Thu, Dec 20, 2018 at 09:55:25PM +0100: > I have now submitted a request to add such a method to POSIX. Here: > http://austingroupbugs.net/view.php?id=1220 Yes, i had seen that request. > I used OpenBSD 6.2 as an example in there, not to bash OpenBSD, Nothing is wrong with bashing OpenBSD when it is at fault. ;-) > but to prove that POSIX is incomplete so far. Which I should probably > have done as early as 2005, when I noticed that the API is incomplete > regarding GNU libc: > https://sourceware.org/ml/libc-alpha/2005-03/msg00125.html There can be no doubt that the POSIX locale system is incomplete in many ways. I do doubt that making it complete is feasible or even desirable - trying to seems more likely to result in bloat than to result in anything that might actually become complete in the end. That said, i like the general approach of the ticket you submitted: Do one very specific thing that can be argued to be particularly important and that can also be argued to be a gap, because there already is related functionality on more than one side: setlocale(NULL) on one side, uselocale() on another side. I'm not completely convinced the interface you propose is the best design possible or really urgently needed, but i don't see off the top of my head how to make it better (i.e. simpler), either. I think i now see your point why setlocale(3) is not only useful to configure the behaviour of *wc* and *mb* functions, but also for standardized communication among various parts of a program, and why something similar for uselocale(3) might possibly make sense. Though i don't claim to anticipate all the dragons one might encounter going that way. [...] > When you apply similar thought to LC_NUMERIC functionality, you can > achieve good results. But I agree it's easy to introduce bugs in this > area. Just last week, by mistake, I wrote code that prints a port number > in a localized way: 8,080 or 8.080 depending on locale. Ouch. Ouch indeed. You strengthen my determination to oppose any support for LC_NUMERIC and the like in OpenBSD. We really don't want functionality that makes bugs and vulnerabilities more likely, and even less so when it only serves relatively arcane, rarely needed purposes. The unavoidable complexity of internationalized UI programming must not introduce additional risks into pure-libc systems programming. Such stuff belongs into GUI programming kits, not into libc. [...] > You would better look at a GNU gettext release: > https://ftp.gnu.org/gnu/gettext/gettext-0.19.8.1.tar.gz > There, in the gettext-runtime/intl/ directory, you will find the > localename.c file - which is my attempt at overcoming the lack of > a locale name getter function in POSIX - and its use for gettext(). Ah. I hope you aren't offended that i won't study that code right now in detail unless the following conclusion happens to be mistaken. I suspect that i understand the situation well enough from your short description to conclude that the bug might not be in gnulib at all, but possibly rather in gettext. On the one hand, gnulib seems right - without the patch you submitted to this list - to detect that OpenBSD now provides uselocale(3). So i'm not so sure the patch you submitted here is a good idea. On the other hand, if i understand correctly what you are saying, gettext expects some behaviour of newlocale(3) that isn't really required by POSIX, and then jumps to conclusions about how the locale_t objects returned from uselocale(3) can be used. It seems to me that, if gettext wants to use non-standard features of newlocale, it is gettext that should test whether the specific extension features it wants to use are available. I'm not sure that is gnulibs task. And even if people here think that doing *something* in gnulib to help people deal with this situation makes sense, than disabling the interface altogether looks like throwing the baby out with the bathwater, when only specific non-standard ways of using the interface are unsupported... Also, a very brief look at localename.c in gettext gives me the impression that it might be using an inconsistent mixture of (good) feature tests and (always somewhat fragile) operating system name tests. For example, the function gl_locale_name_thread_unsafe() appears to be compiled in and used without further conditions when autoconf concludes HAVE_USELOCALE, but then the function doesn't appear to do anything useful unless __GLIBC__, __FreeBSD__, or __APPLE__ are defined. Given that at least three different APIs to deal with the task you are describing in the Austin group ticket are already implemented in various operating systems, this is likely not the best time to implement any additional functionality in OpenBSD. A better time for doing so might be when the dust has settled and the Austin group has made a descision which among the several options will be considered the standard one. In particular since your goal of having a standard way to communicate among various parts of a program can hardly be reached anyway, as long as there are several competeting tools and none of them generally available. Besides, locale support certainly isn't the focus of OpenBSD development goals, so a "wait and see what other free projects more invested in this particular business can agree on" looks like a somewhat reasonable approach to me. Yours, Ingo