Hi Martin, On Sun, Jul 07, 2024 at 02:21:17PM GMT, Martin Uecker wrote: > Am Sonntag, dem 07.07.2024 um 13:07 +0200 schrieb Alejandro Colomar via Gcc: > > Which is actually having perfect information, regardless of 'restrict' > > on nptr. :-) > > Yes, but my point is that even with "restrict" a smarter > compiler could then also be smart enough not to warn even > when *endptr aliases nptr.
Hmmm, this is a valid argument. I feel less strongly about this proposal now. I'll document this in the proposal. Your analyzer would need to be more complex to be able to not trigger false positives here, but it's possible, so I guess I'm happy with either case. Still, removing restrict from strtol(3) would allow to change the semantics of restrict to be more restrictive (and easier to understand), so that passing aliasing pointers as restrict pointers would already be Undefined Behavior, regardless of the accesses by the callee. But yeah, either way it's good, as far as strtol(3) and gcc-20 are concerned. :) Have a lovely day! Alex > > > You also need to discuss backwards compatibility. Changing > > > the type of those functions can break valid programs. > > > > I might be forgetting about other possibilities, but the only one I had > > in mind that could break API would be function pointers. However, a > > small experiment seems to say it doesn't: > > Right, the outermost qualifiers are ignored, so this is not a > compatibility problem. So I think this is not an issue, but > it is worth pointing it out. Yup. > > Martin -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
