On Fri, Jul 05, 2024 at 09:28:46PM GMT, Jonathan Wakely wrote: > On Fri, 5 Jul 2024 at 21:26, Martin Uecker <muecker@xxxxxxx> 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. How does restrict on nptr (or conversely on *endptr) add any semantic information? Can you please phrase the semantic information provided by it? How is it useful to the caller? How is it useful to the callee? Cheers, Alex > 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. -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
