LARWE's dosfs

I modified it a bit and posted a link to the results in this N.G. some time ago, as described from this snippet of an email to Lewin:

I use it to inspect oddball FAT partitions on drives from certain embedded devices, and have plans to use it in some current projects of mine.

Michael

,

It's not that I've moved on to other things so much as I haven't had time to go through all the effort and testing that's required to do a full release. Just rolling in some anonymously received patches is one thing - putting my name on it is a rather different story. There are about half a dozen patches waiting to be publicized. There is also the fast file I/O support (perhaps better called "more deterministic"), which I have scheduled for public release at the end of May; obviously that release will include bugfixes that I'm aware of to date.

There are definitely a couple of FAT12 bugs. I don't think my test data set is adequate to flush them out. FAT12 is very much the poor cousin :)

Will

Yes, I've used it.

I found a number of faults in the FAT12 code which I fixed and reported to Larwe (though I was never sure that he received them because of his email filtering service). I found also found faults in some code using div (rather than ldiv) as well as in some pointer incrementing.

It all worked quite well in the end.

Andrew

uint8_t is guaranteed to be an 8-bit type, while char is not. The uint8_t type is optional, but if it is provided (in stdint.h), then char must be an 8-bit type, though char may be signed or unsigned.

On an unrelated note, I just noticed that the between paragraphs 4 and

6 of section 6.2.5 of ISO/IEC 9899:1999, it appears that the correct way to designate an unsigned character type should be "unsigned signed char". Paragraph 4 defines "signed char" as one of the five standard signed integer types, and paragraph 6 says "For each of the signed integer types, there is a (but different) unsigned integer type (designated with the keyword unsigned) [...]". It does not state that any part of the designation of the signed integer type can be dropped as part of the construction of the designation of the corresponding unsigned integer type.

This kind of rarified argument would impress me a little more if the code didn't promptly cast all the uint8_t* back to char* to pass to the standard libary string functions. :-)

So whatever property is being aimed for by using uint8_t*, it isn't something which can't survive a simple cast to char*...

Will

{snip}

Thanks for the reply - that's great to hear that you're still thinking about it. I suspect that by the time you release this version, my source will be so far from the original that there will be little benefit in merging, but it will still be useful to compare.

As someone else mentioned, your use of 'div' might be playing somewhat fast-and-loose with signed/unsigned issues - C++ compilers in particular are not very happy with that code - I also suspect on a some platforms the div() ends up doing a lot of unused work too, because either the / or the % isn't used from any one call.

Regards,

Will

Maybe you could put them on a website and let others decide how to use them.

I should point out that DOSFS was not developed as an in vitro computer science project; it was originally a very small module in a much larger piece of firmware in a real product. Without going into details (as I don't remember them), the uint* declarations all come from the coding style requirements of the containing project. The containing project also had no standard library, so part of the extraction process involved changing over to str* functions.

I guess it depends on the situation. Wouldn't want to make sure that an item who's target was an 8 bit register was in fact 8 bits, so an architecture that could move around bigger words too didn't do the old even/odd thing and attempt to write a mutibyte value to the registers, but the library expects a native word when taking an argument, for stack alignment or some such. I'm not saying that is the case, but it came quickly to mind. As usual, I could be talking out my ass. :)

Jim

I should point out that DOSFS was not developed as an in vitro computer science project; it was originally a very small module in a much larger piece of firmware in a real product. Without going into details (as I don't remember them), the uint* declarations all come from the coding style requirements of the containing project. The containing project also had no standard library, so part of the extraction process involved changing over to str* functions.

OK, that makes sense - neither clever nor sinister...

I effectively pushed all the casts up another level, at which point they were all unecessary - I can at least feel relaxed that I didn't miss anything important in doing that.

Will