[cfe-dev] clang-tidy or static analyzer or ...

[Billy O'Mahony via cfe-dev]

Hello,

I'd like to write a rule for either clang-tidy or static analyzer to help
catch some potential errors in a project I'm working on.

My questions are:
    a) is only one or the other will be able to do what I want to do?
    b) if both are feasible which would have the simpler implementation?

The project involves writing an API that will run in a multi-threaded
application and is responsible for serializing all access to a device
structure. Therefore the first thing in every function in the API must be
to call api_enter (which will among other things acquire a mutex on the
device) and the last thing before returning must be to call api_exit. Also
I want to enforce single exit point from every API function - or certainly
if there are any return points that bypass the api_exit call.

So here is an example function with errors I want to catch highlighted.

int api_foo(device_t *dev) {
    int ret_val = 0;

    bar();  // fn calls & decls before api_enter is ok- just don't access
dev.
    dev->bla = 1; // NO! device access before api_enter() called
    api_enter(dev);   // error if this call is not present exactly once

    if (dev->bla)
        return; // NO! didn't call api_exit before rtn. Also two return
points

    if (dev->ma) {
        ret_val = 1;
        goto cleanup;
    }
    tweak(dev);

cleanup:
    api_exit(dev); // error if this is not present exactly once
    dev->bla = 1; //NO! device access after api_exit()
    return ret_val;
}

I don't think it matters but the project is C compiled with gcc.

Also if both are feasible any other pointers, tips or good resources would
be appreciated. E.g  is there a totally different methodology I'm not
considering - e.g. would using something like pycparser be a lot easier -
though I'd prefer to keep it in clang as we plan to use tidy & static
analyzer in any case for standard QA.

Thanks for reading,
Billy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190702/df0a482d/attachment.html>