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.
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.
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.
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?
Thanks for your guidance.
Tomás
