Re: [Info-mtools] mtools-4.0.17, big disks, 64bit off_t

[Ignatios Souvatzis]

Hi,

On Wed, Aug 08, 2012 at 04:10:51PM +0200, Alain Knaff wrote:

> Thanks for your contribution, but this patch defines size_t to be the
> same off_t .  These are not the same (most notably, size_t is usually
> unsigned whereas off_t is signed).
> 
> Is this intentional?

mt_size_t, yes.

> I mean, does NetBSD really have a 64 bit off_t but only a 32 bit size_t?

Yes, on 32bit systems, of course. C Language variables can only be
2^32 bytes maximum on such machines - so size_t is a 32bit type -
but files in the filesystem are independent of that, and seek and
friends use the 64bit off_t. (mmap() is a special case - it uses
off_t for the offset but size_t for the size of the map region).

It's the same on all 4.4BSDlite-derived OSes, to my knowledge -
which would include NetBSD 1.0 and later, FreeBSD and OpenBSD from
a similar year and probably Darwin/MacOS, DragonFlyBSD and MirBSD.
 
> (I know, a similar "hack" is already in place for loff_t, but now that I
> think about it, that should probably be revisited as well...)

mtools uses off64_t for mt_size_t, too - same problem, in theory; at
least on Solaris off64_t seems to be signed.

The real confusion might be - if I recall right - that mt_size_t is
used for the size of the filesystem measured in sectors, (in
findDevice() and fs_init()). Judging by that (but I didn't read
all the mtools code) it is not used as something like size_t but
as something like an off_t. I don't know whether mt_size_t is used
elsewhere as a synonym for size_t.

Maybe just use mt_off_t instead, if you really want to clean up, in that
place?

In the meantime, I can r/w 16GB USB flash media with mtools 4.0.17+my
patch very nicely.

Regards,
        -is
-- 
seal your e-mail: http://www.gnupg.org/