From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by sourceware.org (Postfix) with ESMTPS id 20D5C385783A for ; Fri, 20 Aug 2021 13:30:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20D5C385783A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-f54.google.com with SMTP id u22so20582564lfq.13 for ; Fri, 20 Aug 2021 06:30:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=UVykeZBhFGFF5RYOiaFFCarZEfCMXWYExO31SZX2P/E=; b=khH+VRBV42jFqfdbZkdEVI27860LKgc/K9Aj4CQoiyqTJRH5S8OpawcTg9/G2n3ncF Zb0YQ4+Wy1LvZI3/Q5NhBvPz3QwzgZdKn4Jp08x3dCZgl9Wjra+/dEc5tIjoCq/W5ayT j+Pn8Em25FSwpCJSlc5gobkq2UYlRqgZmXbkJzAw0e1VKWz2QNIRgejSWheI4V/JkI0i lwfRF4l1tT10o3FMcyqaYNJXesSgOFS77HCRA1bKxWoZWt6NV1AwotEJRzxfGdibFiMR 4BpaVUWSvSYO6Wx9D5RM8UFWNe7lrJHqT1mE1P4n1mAy+mG7MAHm03BkN0sVKfanfzug lGRA== X-Gm-Message-State: AOAM5314oiUaDosQOPWi3eV+Vrwbto0PEYMFeeEE5LSkAN5YS0nmBaii 5tsbLrEML9Vh3CEreIq8zTe5uK8ExWMajw== X-Google-Smtp-Source: ABdhPJyN8NLrGww1Lp05B5vuW/dBXwN+MoqvFBA7u8fXJQn05TJ+Lpe7/dyTSURlx5XLF+lOhBo7hQ== X-Received: by 2002:ac2:5fd1:: with SMTP id q17mr15014937lfg.439.1629466208602; Fri, 20 Aug 2021 06:30:08 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id t2sm540273ljk.125.2021.08.20.06.30.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Aug 2021 06:30:07 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id z2so20712654lft.1 for ; Fri, 20 Aug 2021 06:30:06 -0700 (PDT) X-Received: by 2002:a05:6512:3408:: with SMTP id i8mr15228830lfr.525.1629466206844; Fri, 20 Aug 2021 06:30:06 -0700 (PDT) MIME-Version: 1.0 References: <02e001d79516$ee6eb1d0$cb4c1570$@nextmovesoftware.com> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Fri, 20 Aug 2021 08:29:55 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Should libc/locale/lnumeric.c be in GENERAL_SOURCES (EL/IX level 1)? To: Newlib , Roger Sayle Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3037.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 13:30:20 -0000 On Fri, Aug 20, 2021 at 3:32 AM Corinna Vinschen wrote: > > On Aug 19 17:26, Roger Sayle wrote: > > > > > > I believe that newlib/libc/locale/Makefile.am should place lnumeric.c > > > > in GENERAL_SOURCES [EL/IX level 1]. The motivation for doing this is > > > > that both stdlib/strtod.c and stdlib/gdtoa-gethex.c unconditionally > > > > call __get_numeric_locale, and they themselves are in GENERAL_SOURCES > > > > (i.e. EL/IX level 1). The FACE Technical Standard (https://opengroup.org/face) has four POSIX profiles which were designed with security and avionics certification in mind has no locale support in the lowest three profiles and only limited support in the largest profile. The Software Communications Architecture (SCA) has a few profiles and targets software defined radios (https://sds.wirelessinnovation.org/history-of-the-sca). It does not include any locale support. The intended users would likely also be subject to security audits. With that background, making locale as optional as possible is a good idea for footprint both in code size and what might need to be audited. I'm happy with the patch. --joel > > Hmm, I wonder if we shouldn't rather fix this in strtod.c and > gdtoa-gethex.c. If the target doesn't define __HAVE_LOCALE_INFO__, > there's not much of a point to call __get_numeric_locale(loc). > Rather, decimal_point could just be set to the dot, i.e. > > diff --git a/newlib/libc/stdlib/gdtoa-gethex.c b/newlib/libc/stdlib/gdtoa-gethex.c > index 1d3da2889ea1..74f30e69013d 100644 > --- a/newlib/libc/stdlib/gdtoa-gethex.c > +++ b/newlib/libc/stdlib/gdtoa-gethex.c > @@ -149,10 +149,16 @@ gethex (struct _reent *ptr, const char **sp, const FPI *fpi, > int esign, havedig, irv, k, n, nbits, up, zret; > __ULong L, lostbits, *x; > Long e, e1; > - const unsigned char *decimalpoint = (unsigned char *) > +#ifdef __HAVE_LOCALE_INFO__ > + const unsigned char *decimalpoint = (const unsigned char *) > __get_numeric_locale(loc)->decimal_point; > - size_t decp_len = strlen ((const char *) decimalpoint); > - unsigned char decp_end = decimalpoint[decp_len - 1]; > + const size_t decp_len = strlen ((const char *) decimalpoint); > + const unsigned char decp_end = decimalpoint[decp_len - 1]; > +#else > + const unsigned char *decimalpoint = (const unsigned char *) "."; > + const size_t decp_len = 1; > + const unsigned char decp_end = (unsigned char) '.'; > +#endif > > havedig = 0; > s0 = *(const unsigned char **)sp + 2; > diff --git a/newlib/libc/stdlib/strtod.c b/newlib/libc/stdlib/strtod.c > index 019416ca7026..ca6d79040224 100644 > --- a/newlib/libc/stdlib/strtod.c > +++ b/newlib/libc/stdlib/strtod.c > @@ -263,7 +263,11 @@ _strtod_l (struct _reent *ptr, const char *__restrict s00, char **__restrict se, > #ifdef Honor_FLT_ROUNDS > int rounding; > #endif > +#ifdef __HAVE_LOCALE_INFO__ > const char *decimal_point = __get_numeric_locale(loc)->decimal_point; > +#else > + const char *decimal_point = "."; > +#endif > int dec_len = strlen (decimal_point); > > delta = bs = bd = NULL; > > This would also avoid to pull in a readonly struct which is never used. > > > Thoughts? > > > Corinna >