From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id EB7F4385E010 for ; Mon, 31 Jan 2022 15:26:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB7F4385E010 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-587-f8dIP3lkPcCGN4IE5Tr3bA-1; Mon, 31 Jan 2022 10:26:54 -0500 X-MC-Unique: f8dIP3lkPcCGN4IE5Tr3bA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3988719253D0; Mon, 31 Jan 2022 15:26:53 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.205]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 46EDA798A3; Mon, 31 Jan 2022 15:26:52 +0000 (UTC) From: Florian Weimer To: Carlos O'Donell Cc: libc-alpha@sourceware.org, michael.hudson@canonical.com Subject: Re: [PATCH 1/2] localedef: Fix handling of empty mon_decimal_point References: <20220131053442.3995804-1-carlos@redhat.com> <20220131053442.3995804-2-carlos@redhat.com> Date: Mon, 31 Jan 2022 16:26:50 +0100 In-Reply-To: <20220131053442.3995804-2-carlos@redhat.com> (Carlos O'Donell's message of "Mon, 31 Jan 2022 00:34:41 -0500") Message-ID: <87bkzs7wp1.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 31 Jan 2022 15:26:57 -0000 * Carlos O'Donell: > diff --git a/locale/programs/ld-monetary.c b/locale/programs/ld-monetary.c > index 277b9ff042..3b0412b405 100644 > --- a/locale/programs/ld-monetary.c > +++ b/locale/programs/ld-monetary.c > @@ -207,7 +207,6 @@ No definition for %s category found"), "LC_MONETARY"); > > TEST_ELEM (int_curr_symbol, ""); > TEST_ELEM (currency_symbol, ""); > - TEST_ELEM (mon_decimal_point, "."); > TEST_ELEM (mon_thousands_sep, ""); > TEST_ELEM (positive_sign, ""); > TEST_ELEM (negative_sign, ""); > @@ -257,6 +256,7 @@ not correspond to a valid name in ISO 4217 [--no-warnings=intcurrsym]"), > record_error (0, 0, _("%s: field `%s' not defined"), > "LC_MONETARY", "mon_decimal_point"); > monetary->mon_decimal_point = "."; > + monetary->mon_decimal_point_wc = L'.'; > } > else if (monetary->mon_decimal_point[0] == '\0' && ! be_quiet && ! nothing) > { > @@ -264,8 +264,6 @@ not correspond to a valid name in ISO 4217 [--no-warnings=intcurrsym]"), > %s: value for field `%s' must not be an empty string"), > "LC_MONETARY", "mon_decimal_point"); > } > - if (monetary->mon_decimal_point_wc == L'\0') > - monetary->mon_decimal_point_wc = L'.'; > > if (monetary->mon_grouping_len == 0) > { There's an existing comment /* The decimal point must not be empty. This is not said explicitly in POSIX but ANSI C (ISO/IEC 9899) says in 4.4.2.1 it has to be != "". */ that says that empty strings/null characters are invalid. The comment was clearly copied from locale/programs/ld-numeric.c. *However* we have got this code in stdio-common/printf_fp.c: decimal = _nl_lookup (loc, LC_MONETARY, MON_DECIMAL_POINT); if (*decimal == '\0') decimal = _nl_lookup (loc, LC_NUMERIC, DECIMAL_POINT); decimalwc = _nl_lookup_word (loc, LC_MONETARY, _NL_MONETARY_DECIMAL_POINT_WC); if (decimalwc == L'\0') decimalwc = _nl_lookup_word (loc, LC_NUMERIC, _NL_NUMERIC_DECIMAL_POINT_WC); So we use LC_NUMERIC as the fallback, and our strfmon implementation is okay with it. But our localeconv implementation lacks this fallback, which looks like a bug because the built-in C locale uses an empty string/a null character. Still I think simplifying the locale data is the right direction here. Thanks, Florian