Hi Jonathan, On Fri, Jul 05, 2024 at 08:38:15PM GMT, Jonathan Wakely wrote: > On Fri, 5 Jul 2024 at 20:28, Alejandro Colomar <a...@kernel.org> wrote: > > > > Hi, > > > > On Fri, Jul 05, 2024 at 06:30:50PM GMT, Martin Uecker wrote: > > > Am Freitag, dem 05.07.2024 um 17:24 +0100 schrieb Jonathan Wakely: > > > > On Fri, 5 Jul 2024 at 17:02, Xi Ruoyao via Gcc <gcc@gcc.gnu.org> wrote: > > > > > > > > > > On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote: > > > > > > At least, I hope there's consensus that while current GCC doesn't > > > > > > warn > > > > > > about this, ideally it should, which means it should warn for valid > > > > > > uses > > > > > > of strtol(3), which means strtol(3) should be fixed, in all of ISO, > > > > > > POSIX, and glibc. > > > > > > > > > > It **shouldn't**. strtol will only violate restrict if it's wrongly > > > > > implemented, or something dumb is done like "strtol((const char*) &p, > > > > > &p, 0)". > > > > > > > > > > See my previous reply. > > > > That's not right. See my reply to yours, Xi. The restrict in > > > > char **endptr > > > > already prevents calls such as strtol(x, x, 0). > > That seems to contradict footnote 153 in C23.
Did you mean a different footnote number?
Here's 153 in N3047:
153) An implementation can delay the choice of which integer type until
all enumeration constants have been seen.
which seems completely unrelated.
Cheers,
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
