800 lines of assembler code basically means just 800 assembler (CPU) instructions - for a complete FAT32 filesystem driver? I really hardly doubt that unless seen. :-)

Any way to opensource that or anything else to comment on your shockinly few 800 assembler instructions? ;-)

Not to detract from the overall point but a small nitpick. Lines of assembler don't always translate directly to CPU instructions. Some assemblers provide high level assembler instructions for commonly used series of instructions. It will be one assembler instruction that would translate to a couple CPU instructions.

Depending on the amount of abstraction involved, it doesn't sound impossible to do. Given sane and direct access to the controller of the underlying device, and a reasonably simple underlying device (e.g. a simple Flash device), raw reads and writes can be written in maybe two dozen instructions each. Assuming userbinator was using a reasonable macro assembler, so that the 800 lines didn't also include string comparisons and all that, 800 lines doesn't look so little. I'm not sufficiently familiar with FAT32 but given a sane enough architecture, it doesn't sound that impossible.

Depends what you mean by "complete", but being able to create/read/write/delete files and directories is pretty complete to me. It doesn't take very many instructions to traverse a linked list or index an array, the two primary structures in FAT32.

Sorry I can't opensource it (being for a commercial product) but this is the approximate breakdown of that ~800 lines (I didn't count exactly, there are comments and whitespace included here too):

    70  initialisation
    140 cluster chain operations
    300 directory operations
    240 higher-level module interface
    50  data area (buffers, states, etc.)

Given sane and direct access to the controller of the underlying device, and a reasonably simple underlying device (e.g. a simple Flash device), raw reads and writes can be written in maybe two dozen instructions each.

It calls into another driver for accessing the block device, so all block read/write operations take the ~6 instructions needed for a call.

Assuming userbinator was using a reasonable macro assembler, so that the 800 lines didn't also include string comparisons and all that, 800 lines doesn't look so little.

I didn't use a macroassembler. It's for an 8-bit MCU; the final firmware image (including all the other functions of the product) is roughly 20KB.

Aye, it's an MCU I was thinking of in the first place, where read/write operations are done through a reasonably simple Flash controller and can be abstracted in a separate driver. I have written FS drivers of fairly similar complexity, in pretty much similar space constraints. That's why I wasn't incredulous.

it is more about the attitude of a C programmer versus the attitude of a, say, JavaScript or Ruby programmer. Whilest the latter merely assumes "nah, the VM will catch all null pointers as soft exceptions for me, and all exceptions I don't catch, my caller should." the first kind of programmer has learned (the hard way) to respect as much of the error codes a function call can return. "The hard way" is the malicious smiled SIGSEGV dynamic-programming language programmers may laughter about, because it hardly crashes your program, one may say.

However, I do believe, that this attitude to think first (how to program right) rather than trying to remember (what could have caused that many 500's on my HTTP server) which I think is the better approach to write more reliable software.

Dynamic languages are said to be more convenient for web sites, for example, I'm not denying that one, but those languages just shift the problems back into the future, where, when time has come, you may or may not be willing to attempt to fix the bug you introduced days/weeks/months ago, depending on the urgency.

On programming environments (such as C), where types are more statically typed, errors have to be handled manually and with caution, memory has to be managed (more or less) always with an ownership in mind, those programs, that think about these topics from the very beginning, and iron out those remaining bugs over time, are - from my point of view - the more reliable ones.

So I can out of my distance second this blog post. It was interesting to read.