On Fri, Jul 05, 2024 at 09:28:46PM GMT, Jonathan Wakely wrote:

On Fri, 5 Jul 2024 at 21:26, Martin Uecker [off-list ref] wrote:

quoted

Am Freitag, dem 05.07.2024 um 21:28 +0200 schrieb Alejandro Colomar:

...

quoted

quoted

quoted

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.

quoted

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/>