On Sun, 2026-03-15 at 10:28 +0100, Tomás Ortín Fernández wrote: > Hi David, > > > > 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. > > I agree with this. In that case, would it make the most sense to > make > it be a 175 hours project, given that it will be of moderate > difficulty? > Do you or the GCC project have a preference of this? I'm open to > either 175h or 350h.
I have a preference for 175 hours for this project; there seem to be a lot of strong candidates for -fanalyzer projects, so I'd prefer to have a smaller projects. > > > > > 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. > > Not any interesting ones yet, as I wasn't familiar with CERT before > (other than it existed). There are some low-hanging fruits that can > easily be implemented while working on adding more known functions, > such > as "MSC24-C. Do not use deprecated or obsolescent functions". I'm > reading the SEI CERT guidelines and taking notes of some potentially > interesting ones, I'll let you know when I have some interesting > candidates. (nods; thanks) > > > > 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). > > I like this approach. The list could be comprised of groups of > related > functions (if that's the case for a given function) that require > similar > checks, instead of individual functions. I could first tackle easy > cases such as the `mkstemp` one, and cases where a very similar check > is > already present for a different function in kf.cc. And then move on > to > tackle more complex and novel cases, and maybe some interesting CERT > rules. > > > One possible early task might be populating our bugzilla with more > > RFE > > bugs to cover possible POSIX entrypoints and CERT checks of > > interest. > > It makes a lot of sense for this to be the first stage of the > project. > > I agree with your proposed approach, and will write the GSOC proposal > based on it. A problem I see for that is that the proposal should > have > a clear scope. > > I could compile a backlog now and use it in the proposal, making > clear > that I intend to get most of it implemented, but it's likely that > this > backlog will need to be modified once the list of areas to improve is > further expanded during the first stage. > > Another option could be to state a number of additional C and POSIX > functions to be covered (e.g. "adding static analysis checks for 100 > currently uncovered functions in the C or POSIX standards"), although > that doesn't mean much: some functions and some checks are trivial, > some > other not so much. I don't like the idea of a specific number, and 100 sounds high. I prefer a more subjective one, where e.g. we try to tackle maybe 1-2 families of functions per week (???), but I expect the time taken to vary considerably based on complexity. > > Lastly, it could be something much less specific such as > "significantly > expand the coverage of the POSIX API", but I'm not sure if this would > be > acceptable, as it's entirely subjective. > > What approach would you recommend? It's likely that I'm missing a > better > way to delimit the scope of the API coverage part of the project. > > > > 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. > > About this: all these functions share an almost identical check on > the > correctness of the template string. I assume it would be preferable > for > this to be a single warning that enables (or disables) the check for > all > these functions. Is this correct, or should each of them have its > own > independent template string warning? Each new warning flag adds a cognitive burden to both GCC users and maintainers, so they should all share one warning flag. Dave
