Most of the users in ~arch will probably have noticed a new major version of dosfstools, 3.0.0. More information about of this release can be found on Daniel’s blog.
A very good question now would be asking why would I be blogging about this, considering I’m not the maintainer of dosfstools, I didn’t bump it, nor I have any bug open about it. The reason is actually simple: I have a masochistic interest in renewing code for old, important utilities. This is probably the reason why I started unieject in the first place: the old eject utility for FreeBSD was just bitrotting.
So once I had the opportunity to clone Daniel’s repository, I decided to start hacking a bit at it in the free time I took out of lscube hacking. The first step was, quite obviously, replacing the build system with autotools, which was already in Daniel’s plans. The straight replacement was quite easy and quick, although I guess there might be need for more fine-tuning in the future. The nice thing about autotools is of course that you can check for most of the extensions you might want to use in your code, be them compiler extensions or operating system extensions, but it’s also quite a mess when you have to check for each and every feature, function, include file, and so on.
My solution to reduce the amount of feature testing needed is to use modern standards, starting from C99, that ensures you of the presence of certain includes, features, and so on. This includes some boolean support (stdbool.h), the offsetof macro, standard integer types and so on so forth. So the next step was to push C99 support on autoconf, and make sure the code still builds with C99 features turned on (this usually encounters problems with the inline functions support).
The rest of the changes have been my usual checklist for software: cowstats and missingstatic, various warnings, and so on. But I then branched off again to try a different thing: using glib for dosfstools; there are a few things where glib can be useful for such a software: byte swapping macros (that are almost certainly faster with glib, since it supports assembler byte swapping macros under many platforms, included ARM if I remember correctly, which, being big endian, is a place where dosfstools would be using byte swapping a lot), command-line options parsing (which right now are quite messed up), lists, …
The move to glib is not yet convincing, it’s still a low-level system utility set that we’re talking about, and glib is not exactly a system library, yet. It might be especially a problem for uClibc-based systems, which would be bad and would drive the experiment to a cliff, but git makes branching for testing quite pleasant so it’s no problem, I guess.
For those interested to take a look to the modified code, it’s available, as usual on my git repository.
