[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 22 April 2016 at 15:48, Evan Huus <eapache@xxxxxxxxx> wrote:

On Fri, Apr 22, 2016 at 10:24 AM, Jeff Morriss
<jeff.morriss.ws@xxxxxxxxx> wrote:
>
>
> On Fri, Apr 22, 2016 at 3:28 AM, Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
> wrote:
>>
>> Just thinking for this for about 30 secs, is there another way?  checkAPIs
>> seems to be a very rudimentary (not meant in any derogatory way just because
>> it's written in Perl :_)) static code analyser.  Is there any way an actual
>> code analyser could be used with a configuration file listing the banned
>> API's etc.?  I guess one issue with that approach is that all the static
>> analysers I've used are quite slow, although that's maybe because I have
>> them turned up to 11.
>
>
> There are; someone (Evan?) suggested a couple of options a few years ago but
> I guess no one had enough interest to do anything about it.  But either my
> memory is wrong or my Google-fu isn't working well today because all I'm
> finding is a suggestion from Sebastien way back in 2008 (I really thought it
> was discussed more recently than that--and with more suggestions):
>
> https://www.wireshark.org/lists/wireshark-dev/200805/msg00128.html

I think I remember talking about http://cppcheck.sourceforge.net/ -
IIRC it lets you define custom rules either as regexes or as more
complex scripts on the C/C++ AST, though I haven't looked at it in a
while.

Interestingly I just ran cppcheck on Wireshark this week which turned up some interesting stuff as cppcheck has "knowledge" of frameworks such as gtk and qt (and windows) and thus is aware of when allocations have been made by library calls and should be cleaned up, e.g. line 119 of packet-pmproxy.c:

    return g_strcmp0(pmproxy_exchange_string, g_strdup_printf("pmproxy-%s 1\n", type)) == 0;

The g_strdup_printf() allocates a string which has to be freed with g_free().

> Of course I doubt such tools could fully replace checkAPIs: it has a lot of
> custom stuff in there like ensuring various arrays are NULL terminated and
> that hf fields are appropriate (writing the regex to match all the hf array
> entries was all sorts of challenging fun :-)).

This may be somewhere a little bit of AST might go a long way, but it
would certainly be a lot of work to migrate everything over.

This was the approach I was thinking, once you have an AST and a symbol table, lots of things are possible.

 

> (You really should just come on over to the world of Perl; eventually you'll
> wonder how you ever got along without it! ;-))
>

Tried that once, still feel unclean.  Only php is worse, mainly due to the huge amount of insecure php web apps I have run into.

--

Graham Bloice