"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

In article <48237bd5$0$652$bed64819@news.gradwell.net>, 
will@nospam.demon.co.uk says...
> "Eric Smith" <eric@brouhaha.com> wrote in message 
> news:m3ve1o37pd.fsf@donnybrook.brouhaha.com...
> > "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.
> 
> 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
> 

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

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

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

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.

On May 8, 10:21 am, larwe <zwsdot...@gmail.com> wrote:
> On May 8, 10:10 am, "Will Dean" <w...@nospam.demon.co.uk> wrote:
>
> > 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.
>
> 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.

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

"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}
> 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.

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

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

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

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

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.

Will

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

Yes, I've used it.

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

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.

> 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.

It all worked quite well in the end.

	Andrew

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

> 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.

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 Dean wrote:

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

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:

> The attached diffs document some trivial patches to permit
> mixed-case pathnames and FAT16 < 16MB support. There are
> also changes to DFS_OpenFile I needed to make to permit
> working with files in the root directory; without them
> a pointer to the filename backed-up one character too many
> and there was no detection for a pathname without a separator.

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