Mail Archives: djgpp-workers/2002/06/14/14:44:18
Hello.
I've just started working on getting Large File Summit (LFS) support in DJGPP.
Basically this is a way of supporting files which exceed the number of bytes
representable by a positive signed 32b integer, i.e.: 2GB - 1B. LFS has been
integrated into the new POSIX standard.
Here's my plan, after looking at the LFS document from
http://ftp.sas.com/standards/large.file/ :
1. Add the transition API: These are the *64() functions, which take an
off64_t instead of an off_t. We have ftello64(), which is a 64-bit variant of
ftell(). There are *64 equivalents for many stdio and unistd I/O functions.
2. Limit the current functions to working with up to 2GB - 1B. Currently we
sort of support writing to 4GB files. But we do this by using the negative
portion of a signed integer to mean positions >= 2GB. This is broken IMHO. So
the library functions will be changed to support the idea of a "maximum
offset" (2GB - 1) and will not be allowed to go beyond that. The EOVERFLOW
error will be set, if a call is made to go beyond the maximum offset.
3. Allow selection, at compile time using the _LARGEFILE_SOURCE macro, between
32b and 64b offsets. This involves choosing between the normal and *64
versions of functions.
To support part 2, file descriptors will gain another flag - whether they were
opened in "large file" mode or not. This determines the "maximum offset".
I've started work on 1 & 2 already. They seem to go hand-in-hand. The existing
functions will become wrappers for the *64 versions, but will do a little more
checking on the results. For instance, ftell calls ftello64, but has to check
that ftello64's result will fit in a long.
We currently have the functions llseek and llockf. These will become stubs for
lseek64 and lockf64.
Incidentally, is it OK to rename the FSEXT hook to __FSEXT_lseek64? I think
that would be more consistent with the APIs, once I've added all the *64
functions. Since llseek is a new function in 2.04, this change would not break
binary compatibility.
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -