On Thu, 2026-03-12 at 20:15 +0100, Tomás Ortín Fernández wrote: > > Thanks for the updated patch. It looks good, and I've added it to > > my > > queue of patches to push to gcc 17 once we reopen trunk for new > > features. > > Thanks! > > > Do you have a sense of what you'd like to look at next? You > > mentioned > > a possible followup to cover similar functions to mkstemp. If > > you're > > planning to apply to GSoC, I'm wondering what subproject you had in > > mind. Note that adding a bunch of known functions to more fully > > handle > > various POSIX APIs in -fanalyzer sounds like a reasonable GSoC > > project > > idea to me; it would be useful and (I hope) relatively easy. > > I was going to ask first if there's anything that would be > particularly > useful for the analyzer.
The big area of missing functionality in -fanalyzer is proper C++ support, but the problems there are difficult (e.g. reworking it to be more scalable). Adding known_function subclasses is a less ambitious project, but also helpful, and has a much gentler learning curve and thus likely to be a more successful project. > If there's not anything in particular, adding > more known functions to cover more of both the C standard and POSIX > would be interesting to me, now that I have some understanding of how > it > works. I'd also be interested in adding support for more SEI CERT > checks, I imagine some of those may be more challenging. That sounds useful. Do you have any specifically in mind? We can brainstorm about how to go about implementing them. > > What I'm not sure is how go about clearly delimiting the scope in the > case of a project of that kind. A predefined list of functions and > checks could easily end up being either too little or too ambitious, > as > it may be hard for me to estimate how difficult some type of check > may > be before having solved a similar one. In this case, what would you > recommend? How about a flexible approach where you come up with a list of functions and checks (a "backlog" in agile parlance, I believe); each item is relatively small and well-contained, and each week you try and implement some from the list, and if any particular item proves harder than expected, we put it back in the backlog and move on to something easier. Maybe as the summer goes on you could try the harder problems. That way you'd be generating a series of non-trivial patches similar to the one you've already done; the analyzer would gain new warnings and improvements to analysis precision; and hopefully by the end of the summer you'd have an impressive set of patches to your credit in gcc trunk, and have more familiarity with the internals of the analyzer/gcc. The expectation would be that you get plenty of patches in; but we wouldn't expect the full list completed during the summer (I'd prefer to capture a more complete list of areas for improvement than to achieve 100% on an incomplete list, if that makes sense). One possible early task might be populating our bugzilla with more RFE bugs to cover possible POSIX entrypoints and CERT checks of interest. > > In summary, I'm open to working on whatever may be more helpful right > now to improve the analyzer. Regardless of what I end up choosing > for > the project proposal, I will now work on an additional patch covering > functions similar to `mkstemp`, as that's a very low-hanging fruit. Excellent; thanks. > > By the way, thank you for your welcoming and helpful attitude. I was > quite intimidated at the idea of approaching a big and complex > project > like GCC, and your willingness to help and provide useful pointers > were > motivating and lessened my worries. My first patch was a very good > experience, and now I want to continue contributing to GCC. Thanks, that's good to hear. Let me know if you have further questions Dave
