[RFC] Clang plugin for catching suspicious typedef casting
От | Dmitry Dolgov |
---|---|
Тема | [RFC] Clang plugin for catching suspicious typedef casting |
Дата | |
Msg-id | 20230803165638.nyjgdqxg7korp54r@erthalion.local обсуждение исходный текст |
Ответы |
Re: [RFC] Clang plugin for catching suspicious typedef casting
Re: [RFC] Clang plugin for catching suspicious typedef casting |
Список | pgsql-hackers |
Hi, In the commit [1] one side change was to fix mixed up usage of BlockNumber and Buffer variables. This was a one-off manual effort, and indeed it hardly seems possible to get compilation warnings for such code, as long as the underlying types could be converted in a standard conforming way. As far as I see such conversions are acceptable and used every now and then in the project, but they may hide some subtle issues. One interesting way I found to address this was to benefit from clang plugin system [2]. A clang plugin allows you to run some frontend actions when compiling code with clang, and this approach is used in some large open source projects (e.g. I've got my inspiration largely from libreoffice [3]). After a little experimenting I could teach such a plugin to warn about situations similar to the one described above. What it does is: * It visits all the function call expressions * Verify if the function arguments are defined via typedef * Compare the actual argument with the function declaration * Consult with the suppression rules to minimize false positives In the end the plugin catches the error mentioned above, and we get something like this: ginget.c:143:41: warning: Typedef check: Expected 'BlockNumber' (aka 'unsigned int'), got 'Buffer' (aka 'int') in PredicateLockPage PredicateLockPage(btree->index, stack->buffer, snapshot); Of course the plugin produces more warning, and I haven't checked all of them yet -- some probably would have to be ignored as well. But in the long run I'm pretty confident it's possible to fine tune this logic and suppression rules to get minimum noise. As I see it, there are advantages of using plugins in such way: * Helps automatically detect some issues * Other type of plugins could be useful to support large undertakings, where a lot of code transformation is involved. And of course disadvantages as well: * It has to be fine-tuned to be useful * It's compiler dependent, not clear how to always exercise it I would like to get your opinion, folks. Does it sound interesting enough for the community, is it worth it to pursue the idea? Some final notes about infrastructure bits. Never mind cmake in there -- it was just for a quick start, I'm going to convert it to something else. There are some changes needed to tell the compiler to actually load the plugin, those of course could be done much better as well. I didn't do anything with meson here, because it turns out meson tends to enclose the plugin file with '-Wl,--start-group ... -Wl,--end-group' and it breaks the plugin discovery. [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=126552c85c1cfb6ce6445159b8024cfa5631f33e [2]: https://clang.llvm.org/docs/ClangPlugins.html [3]: https://git.libreoffice.org/core/+/refs/heads/master/compilerplugins/clang/
Вложения
В списке pgsql-hackers по дате отправления: