On Thu, Jan 31, 2013 at 1:23 PM, Bill Meier <wmeier@xxxxxxxxxxx> wrote:
> On 1/28/2013 3:31 PM, Evan Huus wrote:
>>
>> Tangentially, CppCheck [1] has support for custom checks using
>> plugins. I've never had time to investigate properly, but I suspect
>> that implementing the three check scripts (checkhf, checkAPIs,
>> checkfiltername) as CppCheck plugins would be a major win, primarily
>> because we'd get real C grammar parsing for free.
>>
>> Cheers,
>> Evan
>>
>> [1] http://cppcheck.sourceforge.net/
>
>
> After looking at the cppcheck docs about writing rules & sampling the
> developer's cppcheck forum a bit, lets just say that I don't really get a
> warm feeling about trying to do our special tests with cppcheck.
That's too bad.
> The basic mechanism for adding rules appears to be nothing more than using
> regexs to pick out patterns on a tokenised version of the source program.
>
> One can write rules using C++ code to traverse a tokenised version of the
> code; This doesn't seem much better.
The impression I got during my (admittedly brief) skim was that this
was where the power lay, and that you got more of an abstract syntax
tree than just a set of tokenised strings.
> I didn't see anything about plugins (other than cppcheck being used as a
> plugin by various IDE's). Maybe I missed something....
The simpler regex rules can be added dynamically, so I assumed that
the compiled C++ rules could be as well, but it looks like that
assumption is false.
> I imagine that there's much more capability if I want to really dig into the
> code and see how the existing capability is provided and how more comples
> rules might be written.
>
>
> OTOH, using the CLang library[1] sounds quite interesting. It might be that
> it's possible to fairly easily do what is needed.
I have no particular objection to clang either, if it provides a more
functional base. I've looked at it even less than I've looked at
CppCheck.
Evan
