On Tue, 22 Aug 2017, Derek M Jones wrote:
> Julia,
>
> > 1. More aggressive inclusion of header files, combined with caching of
> > header files. Now if there is only one occurrence of a header file with a
>
> Caching can be dangerous because macros may be defined differently
> for different includes of the same header. An option to switch off
> caching could come in handy.
I believe that macros are only applied if they are defined in the same
file. At this point, I'm not 100% certain of that. But when I ran the
provided test script on the Linux kernel, I list very few functions as
compared to the current --recursive-includes implementation. The lost
functions were due to the recovery strategy, not to macro issues.
The Linux kernel has some declarations like
type fn(a1, a2)
with no trailing ; followed by a function definition. This gives a parse
error on a1. In the previous version, Coccinelle was able to recover an
parse the function definition. In the new version, I comment out the
arguments and then another error is encountered that is after the ). This
causes the recovery process to skip over the subsequent function. The
recovery code is rather subtle to avoid infinite loops, and so far my
attempts to improve it have led to more of a mess than anything else.
The problem could be solved by not trying to patch up errors in
parentheses when they occur at top level. When they occur inside a
function, they should not impact the recovery process.
Basically the recovery process is focused on finding a { in column 0 and
then a } in column 0, and then it goes on after that. But it can go
backwards sometimes, because a parsing problem can cause a parsing attempt
to read too far, into the next function.
>
> > given name in the provided include paths, it will take that one, even if
> > there is no obvious connection between the location of the .c file and the
> > location of the header file. This compensates for the lact of parsing of
> > Makefiles to extract -I options. More header files will likely now be
>
> There is no need to parse Makefiles. Simply create a script, say coc99,
> and configure it as the compiler that make uses. coc99 parses its
> arguments to extract whatever information cocci needs and passes
> everything to the 'real' C compiler as-is.
At least for the Linux kernel, you can't just run one make and get all the
files to be compiled. Some files are indeed very hard to compile. For a
more uniform project this could work, though.
> How is the O'Reilly book coming along ;-)
Still looking for an author :)
julia
>
> --
> Derek M. Jones Software analysis
> tel: +44 (0)1252 520667 blog:shape-of-code.coding-guidelines.com
> _______________________________________________
> Cocci mailing list
> Cocci@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
