Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Paul, On Tue, Jul 09, 2024 at 02:09:24PM GMT, Paul Eggert wrote: > On 7/8/24 00:52, Alejandro Colomar wrote: > > a small set of functions > > accept pointers that alias each other, but one of them is never > > accessed; in those few cases, restrict was added to the parameters in > > ISO C, but

Re: WG14 paper for removing restrict from nptr in strtol(3)

On 7/8/24 00:52, Alejandro Colomar wrote: > a small set of functions > accept pointers that alias each other, but one of them is never > accessed; in those few cases, restrict was added to the parameters in > ISO C, but I claim it would be better removed. Are these aliasing pointers the nptr and

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Tue, Jul 09, 2024 at 12:28:18PM GMT, Alejandro Colomar wrote: > Hi Jakub, > > On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote: > > On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote: > > > Yup, I was thinking that maybe noalias is a better name. > > > > Name is one t

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Jakub, On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote: > On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote: > > Yup, I was thinking that maybe noalias is a better name. > > Name is one thing, but you'd also need to clearly define what it means. > When restrict is a

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Martin, On Tue, Jul 09, 2024 at 07:58:40AM GMT, Martin Uecker wrote: > Am Montag, dem 08.07.2024 um 22:17 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote: > > > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Coloma

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote: > > > restrict, as of what -Wrestrict warns about, seems a reasonable > > > thing. > > > > > > How about a [[gnu::restrict()]] attribute, similar to > > > [[gnu::access()]], > > > which is simpler than the qualifier?  Since restric

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Dave, On Mon, Jul 08, 2024 at 06:48:51PM GMT, David Malcolm wrote: > > restrict, as of the formal definition of ISO C is useless crap.  The > > more I read it, the more I agree. > > Please note that "useless crap" was your wording, not mine. Yup. :) > > > > > restrict, as of what -Wrestri

Re: WG14 paper for removing restrict from nptr in strtol(3)

Am Montag, dem 08.07.2024 um 22:17 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote: > > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar: > > > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > > > ...

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Mon, 2024-07-08 at 17:01 +0200, Alejandro Colomar wrote: > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > > > Why is this change worth > > > > making? Real-world programs do not make calls like that. > > > > > > Because it makes analysis of 'restrict' more consistent.  The > >

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Martin, On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote: > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar: > > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > ... > > And then have it mean something strict, such as: The object pointed to > > by

Re: WG14 paper for removing restrict from nptr in strtol(3)

Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar: > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: ... > And then have it mean something strict, such as: The object pointed to > by the pointer is not pointed to by any other pointer; period. > > This definition is a

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > > Why is this change worth > > > making? Real-world programs do not make calls like that. > > > > Because it makes analysis of 'restrict' more consistent.  The obvious > > improvement of GCC's analyzer to catch restrict violations wi

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Sun, 2024-07-07 at 14:42 +0200, Alejandro Colomar wrote: > Hi Paul, > > On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: > > On 7/7/24 03:58, Alejandro Colomar wrote: > > > > > I've incorporated feedback, and here's a new revision, let's call > > > it > > > v0.2, of the draft for a W

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Paul, On Sun, Jul 07, 2024 at 07:30:43PM GMT, Paul Eggert wrote: > On 7/7/24 14:42, Alejandro Colomar wrote: > > On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: > > > Also, “global variables” is not > > > right here. The C standard allows strtol, for example, to read and write > > >

Re: WG14 paper for removing restrict from nptr in strtol(3)

On 7/7/24 14:42, Alejandro Colomar wrote: On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: Also, “global variables” is not right here. The C standard allows strtol, for example, to read and write an internal static cache. (Yes, that would be weird, but it’s allowed.) That's not part

Re: WG14 paper for removing restrict from nptr in strtol(3)

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

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Paul, On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: > On 7/7/24 03:58, Alejandro Colomar wrote: > > > I've incorporated feedback, and here's a new revision, let's call it > > v0.2, of the draft for a WG14 paper. > Although I have not followed the email discussion closely, I read v

Re: WG14 paper for removing restrict from nptr in strtol(3)

Am Sonntag, dem 07.07.2024 um 13:07 +0200 schrieb Alejandro Colomar via Gcc: > Hi Martin, > > On Sun, Jul 07, 2024 at 09:15:23AM GMT, Martin Uecker wrote: > > > > Hi Alejandro, > > > > if in caller it is known that endptr has access mode "write_only" > > then it can conclude that the content of

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Martin, On Sun, Jul 07, 2024 at 09:15:23AM GMT, Martin Uecker wrote: > > Hi Alejandro, > > if in caller it is known that endptr has access mode "write_only" > then it can conclude that the content of *endptr has access mode > "none", couldn't it? H. I think you're correct. I'll incorpo

Re: WG14 paper for removing restrict from nptr in strtol(3)

On 7/7/24 03:58, Alejandro Colomar wrote: I've incorporated feedback, and here's a new revision, let's call it v0.2, of the draft for a WG14 paper. Although I have not followed the email discussion closely, I read v0.2 and think that as stated there is little chance that its proposal will be a

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Alejandro, if in caller it is known that endptr has access mode "write_only" then it can conclude that the content of *endptr has access mode "none", couldn't it? You also need to discuss backwards compatibility. Changing the type of those functions can break valid programs. You would need

WG14 paper for removing restrict from nptr in strtol(3)

Hi, I've incorporated feedback, and here's a new revision, let's call it v0.2, of the draft for a WG14 paper. I've attached the man(7) source, and the generated PDF. Cheers, Alex -- strtol.man Description: Unix manual page strtol.pdf Description: Adobe