Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3D0A28A4.3329742C@phekda.freeserve.co.uk> Date: Fri, 14 Jun 2002 18:32:20 +0100 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: DJGPP workers Subject: DJGPP and the Large File Summit (LFS) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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/ ]