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 > > > 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. Please note that "useless crap" was your wording, not mine. > > 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. If it doesn't have the same meaning as "restrict" then perhaps call the proposed attribute something other than "restrict"? That said, I don't have strong opinions on any of this, except to note that I have more than enough *other* work on improvements to GCC's static analyzer and usability to keep me busy, so getting sucked into discussion/implementation on 'restrict' is something I want to avoid, and -Wanalyzer-overlapping-buffers is getting the job done for me at the moment. [...snip...] Hope this is constructive; sorry again if I missed anything due to only skimming the thread Dave
