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: > > > > ... > > > 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 already what -Wrestrict seems to understand. > > > > One of the main uses of restrict is scientific computing. In this > > context such a definition of "restrict" would not work for many > > important use cases. But I agree that for warning purposes the > > definition of "restrict" in ISO C is not helpful. > > Do you have some examples of functions where this matters and is > important? I'm curious to see them. Maybe we find some alternative.
In many numerical algorithms you want to operate on different parts of the same array object. E.g. for matrix decompositions you want to take a row / column and add it to another. Other examples are algorithms that decompose some input (.e.g. high and low band in a wavelet transform) and store it into the same output array, etc. Without new notation for strided array slicing, one fundamentally needs the flexibility of restrict that only guarantuees that actual accesses do not conflict. But this then implies that one can not use restrict as a contract specification on function prototypes, but has to analyze the implementation of a function to see if it is used correctly. But I would not see it as a design problem of restrict. It was simply not the intended use case when originally designed. > > > > > Has the C standard clarified the meaning of 'restrict' since that > > > > discussion? Without that, I wasn't planning to touch 'restrict' in > > > > GCC's -fanalyzer. > > > > > > Meh; no they didn't. > > > > There were examples added in C23 and there are now several papers > > being under discussion. > > Hmm, yeah, the examples help with the formal definition. I was thinking > of the definition itself, which I still find quite confusing. :-) Indeed. Martin > > Have a lovely night! > Alex >
