Hi,

Are there many people around on the group who are actually using LARWE's
dosfs in real apps?

I rather like its general style, and the code seems pretty good quality, but
I'm actually starting to suspect it's pretty buggy.

Things I've noticed so far include:

Bug in root-directory allocation for new items in a root directory (this was
mentioned in here last year by someone who posted a fix, thanks to him)
Possible problems with FAT12 (I'm not actually using FAT12, but some of the
code caused compiler warnings, and looks wrong to me)
Doesn't seem to be able to seek properly (gets stuck in an infinite loop)
seeking forward (I haven't debugged this yet - I think it's caused by
seeking forward by exactly one cluster's worth of bytes, or something, which
causes a loop in DFS_Seek to never complete.

Minor irritants are a lack of const-correctness and the use of uint8_t
instead of char (though I'm sure there was a good reason for that).

I think I'm going to persist with it, but if there were other users who'd
fixed problems, I would be interested in shared experiences.

I think Larwe himeself has moved on to other things now, which is fair
enough - it's generous enough to have made it available in the first place,
he certainly doesn't owe me free support.

Thanks,

Will

Will Dean wrote:

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

On May 8, 10:10*am, "Will Dean" <w...@nospam.demon.co.uk> wrote:

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

"Will Dean" <will@nospam.demon.co.uk> writes:
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.

"Eric Smith" <eric@brouhaha.com> wrote in message
news:m3ve1o37pd.fsf@donnybrook.brouhaha.com...
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

"larwe" <zwsdotcom@gmail.com> wrote in message
news:ae1917ad-a4bc-472f-a883-0d5ed8beb003@k13g2000hse.googlegroups.com...
On May 8, 10:10 am, "Will Dean" <w...@nospam.demon.co.uk> wrote:

{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

On May 8, 10:21 am, larwe <zwsdot...@gmail.com> wrote:
Maybe you could put them on a website and let others decide how to use
them.

On May 8, 6:16*pm, "Will Dean" <w...@nospam.demon.co.uk> wrote:

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.

In article <48237bd5$0$652$bed64819@news.gradwell.net>,
will@nospam.demon.co.uk says...
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

"larwe" <zwsdotcom@gmail.com> wrote in message
news:fc35681a-fff1-44fe-b7cd-c9eb10719e08@e53g2000hsa.googlegroups.com...

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