On Fri, 5 Jul 2024 at 21:26, Martin Uecker <muec...@gwdg.de> wrote: > > Am Freitag, dem 05.07.2024 um 21:28 +0200 schrieb Alejandro Colomar: > > ... > > > > > > Showing that you can contrive a case where a const char* restrict and > > > > char** restrict can alias doesn't mean there's a problem with strtol. > > > > > > I think his point is that a const char* restrict and something which > > > is stored in a char* whose address is then passed can alias and there > > > a warning would make sense in other situations. > > > > Indeed. > > > > > But I am also not convinced removing restrict would be an improvement. > > > It would make more sense to have an annotation that indicates that > > > endptr is only used as output. > > > > What is the benefit of keeping restrict there? It doesn't provide any > > benefits, AFAICS. > > Not really I think. I am generally not a fan of restrict. > IMHO it is misdesigned and I would like to see it replaced > with something better. But I also not convinced it really > helps to remove it here. > > If we marked endptr as "write_only" (which it might already > be) then a future warning mechanism for -Wrestrict could > ignore the content of *endptr.
That seems more useful. Add semantic information instead of taking it away. If the concern is a hypothetical future compiler warning that would give false positives for perfectly valid uses of strtol, then the problem is the compiler warning, not strtol. If additional information can be added to avoid the false positives (and also possibly optimize the code better), then that wouldn't require a change to the standard motivated by a hypothetical compiler warning.
