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 will > > trigger > > false positives in normal uses of strtol(3). > > Hi Alejandro Hi Dave, > I'm author/maintainer of GCC's -fanalyzer option, which is presumably > why you CCed me on this. Yup. > One of my GSoC 2022 students (Tim Lange) > looked at making use of 'restrict' in -fanalyzer, see e.g. > https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00062.html > > Based on Paul's comment here: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99860#c2 (and its > references) I came to the conclusion at the time that we should work on > something else, as the meaning of 'restrict' is too ambiguous. restrict, as of the formal definition of ISO C is useless crap. The more I read it, the more I agree. 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 restrict is only meaningful in function boundaries, it would make sense to have a function attribute. We don't want a qualifier that must follow discarding rules. 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. > Later, I added a new -Wanalyzer-overlapping-buffers warning in GCC 14, > which simply has a hardcoded set of standard library functions that it > "knows" to warn about. Hmmm, so it doesn't help at all for anything other than libc. Ok. > 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. I understand. That's why I don't like innovations in ISO C, and prefer that implementations innovate with real stuff. > Sorry if I'm missing anything here; I confess I've skimmed through > parts of this thread. Nope; all's good. > > Dave -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
