[Cocci] Inconsistent control-flow paths?

[Wolfram Sang]

Hello,

I'd need another explanation, please :) Still using this script:

===

@@
type T;
identifier client, data;
@@

// Check if function uses clientdata
(
        i2c_set_clientdata(client, data);
|
        data = i2c_get_clientdata(client);
|
        T data = i2c_get_clientdata(client);
)
// Anything inbetween
        ...
// Check if clientdata gets NULLed before data is freed
(
        i2c_set_clientdata(client, NULL);
        ...
        kfree(data);
|
+       i2c_set_clientdata(client, NULL);
        kfree(data);
        ...
-       i2c_set_clientdata(client, NULL);
|
+       i2c_set_clientdata(client, NULL);
?       kfree(data);
)

===

In general, this works well and finds ~100 occurences, but I get a roughly a
dozen inconsistent control-flow paths when applying this patch to the drivers/
directory. Trying to figure out what is causing this, I just checked
drivers/media/radio/radio-tea5764.c. I found '-show_trying' and it told me the
problem is in tea5764_i2c_probe() which is what I expected, too. I also found
'-allow_inconsistent_paths' which gave me the patch I wanted (but I don't want
to use this function unless I know better what it does).

Just looking at the probe-routine in question, I can't find any inconsistent
control flow paths manually? How can I get more information what is causing
problems? The macros perhaps?

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.diku.dk/pipermail/cocci/attachments/20100310/763dfd07/attachment.pgp