As I've said in my previous posts. I have two CPAN modules that provide bindings for C libraries.
One thing that I have I realized while I was writing these bindings is that sometimes C functions pass under my eyes unnoticed and that I forget to provide bindings for them. This can happen for various reasons:
I asked a few months a go on the gtk-perl-list on how to proceed in order to find the functions that are missing code coverage in the the XS module. I took the suggestions posted in the mailing list and made this script: xs-coverage
I've used this script with a couple of bindings and I was quite satisfied. On my bindings it did find C functions that where missing in the XS files. But this script did even more: it showed me C functions that shouldn't have been public in the first place and undocumented functions in the library! This script is really helping me to improve the code coverage of the bindings that I maintain.
Even though xs-coverage is written in Perl i doubt that it is portable as the program relies on the command nm for inspecting the .so files.Furthermore, so far my script this has been only tested in Linux and could probably only work there. I'm not even sure that the program will work with standard C libraries as I only tested it with Glib based libraries. Another drawback is that the program will not detect XS aliases. Although, Vincent Pit suggested that I might be able to get around that bug by inspecting the functions from the XS module by loading it in the Perl script and walking the package's symbol table.
If you have some suggestions or feed back on the script please let me know or fork it and send patches.
Re:GCC-XML
potyl on 2009-09-28T05:12:20
Thanks for the pointer! I will take a look at the program.
At the time I though one of writing a parser for C header files and XS files, but I didn't find a grammar module in CPAN that was convincing enough. Now that Damian Conway has released Regexp::Grammars I guess that the job could be easier.
Although, I did find an advantage in scanning the
.so libraries. As it clearly shows which functions are made "public" in the C API. It's nice for finding "private" functions that haven't declared as static.