public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: <libc-alpha@sourceware.org>, Carlos O'Donell <carlos@redhat.com>
Subject: Re: [v3] C2x strtol binary constant handling
Date: Mon, 16 Jan 2023 19:23:43 +0000	[thread overview]
Message-ID: <e261a8b-4ad1-7b76-dc7-9bbb87c8b82f@codesourcery.com> (raw)
In-Reply-To: <75b666f9-8a57-62a5-d6d5-81e5919ad264@linaro.org>

On Mon, 16 Jan 2023, Adhemerval Zanella Netto via Libc-alpha wrote:

> I wonder if could reduce the required new symbols for architecture where
> 'long' and 'long long' have the same size, so the REDIRECT macro would
> redirect both strtol and strtoll to __isoc23_strtol.  I am not if the
> complexty really pays off.

In <https://sourceware.org/pipermail/libc-alpha/2020-December/120445.html> 
Carlos argued against redirecting strtoimax strtoumax wcstoimax wcstoumax 
to functions such as __isoc23_strtoll rather than adding functions such as 
__isoc23_strtoimax.  I think the same argument would apply to having a 
single underlying function for both strtol and strtoll (with the 
additional point that redirecting to a function with a different type is 
awkward, in the case where __REDIRECT isn't defined and in the case of 
internal uses in libc where #define is used because __REDIRECT and 
libc_hidden_proto don't interact well).

> > +# Some versions of GCC supported for building glibc do not support -std=c2x
> > +# or -std=gnu2x, so the tests for those versions use -std=c11 and -std=gnu11
> > +# and then _ISOC2X_SOURCE is defined in the test as needed.
> > +CFLAGS-tst-strtol-binary-c11.c += -std=c11
> > +CFLAGS-tst-strtol-binary-c2x.c += -std=c11
> > +CFLAGS-tst-strtol-binary-gnu11.c += -std=gnu11
> > +CFLAGS-tst-strtol-binary-gnu2x.c += -std=gnu11
> > +
> >  
> >  # Run a test on the header files we use.
> >  tests-special += $(objpfx)isomac.out
> 
> Ok, I think it should cover all possible scenarios. Should we also add tests to
> use the expected -std= (it would most likely require a new configure switch to
> check for compile support)?

I'm dubious of the value of adding such a new configure test at this 
point.

-- 
Joseph S. Myers
joseph@codesourcery.com

      reply	other threads:[~2023-01-16 19:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-15  1:37 Joseph Myers
2022-12-15 12:25 ` Alejandro Colomar
2022-12-15 19:09   ` Adhemerval Zanella Netto
2022-12-19 16:02 ` [v2] " Joseph Myers
2022-12-22  0:10   ` [v3] " Joseph Myers
2022-12-30 15:24     ` Ping " Joseph Myers
2023-01-16 13:52     ` Adhemerval Zanella Netto
2023-01-16 19:23       ` Joseph Myers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e261a8b-4ad1-7b76-dc7-9bbb87c8b82f@codesourcery.com \
    --to=joseph@codesourcery.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).