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

[Alejandro Colomar]

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 thing, but you'd also need to clearly define what it means.
> > When restrict is access based, it is clear what it means.
> > 
> > If you want something else which is not based on accesses and which should
> > allow warnings in the callers, I suppose you need to specify not just the
> > pointer but the extent as well (and maybe stride) or that it is an '\0'
> 
> Agree.  Here's how I'd define it as an attribute:
> 
> noalias
> 
> 	The noalias function attribute specifies that the pointer to
> 	which it applies is the only reference to the array object that
> 	it points to (except that a pointer to one past the last
> 	element may overlap another object).
> 
> 	If the number of elements is specified with array notation, the
> 	array object to be considered is a subobject of the original
> 	array object, which is limited to the number of elements
> 	specified in the function prototype.
> 
> 	Example:
> 
> 	[[alx::noalias(1)]] [[alx::noalias(2)]]
> 	[[gnu::access(read_write, 1)]] [[gnu::access(read_only, 2)]]
> 	void add_inplace(int a[n], const int b[n], size_t n);

Ooops, I meant 'n' to be the first parameter.

> 
> 	char arr[100] = ...;
> 
> 	add_inplace(arr, arr + 50, 50);
> 
> 	In the example above, the parameters a and b don't alias inside
> 	the function, since the subobjects of 50 elements do not overlap
> 	eachother, even though they are one single array object to the
> 	outer function.
> 
> It may need some adjustment, to avoid conflicts with other parts of
> ISO C, but this is the idea I have in mind.
> 
> > terminated string, because if you want to say that for
> > void foo (char *, const char *, int);
> > the 2 pointers don't really alias, the size information is missing.  So,
> > shall the new warning warn on
> > struct S { char a[1024]; char b[1024]; } s;
> > foo (s.a, s.b, 512);
> 
> This does not need clarification of bounds.  You're passing separate
> objects, and thus cannot alias (except that maybe you're able to cast
> to the struct type, and then access s.b from a pointer derived from
> s.a; I never know that rule too well).
> 
> > or not?  Or foo (s.a, s.a + 512, 512);
> 
> According to the definition I provide in this email, the above is just
> fine.
> 
> Thanks!
> 
> Have a lovely day!
> Alex
> 
> > 
> > 	Jakub
> > 
> > 
> 
> -- 
> <https://www.alejandro-colomar.es/>



-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20240709/df2d9a24/attachment-0001.sig>