delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/06/14/14:44:18

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 <rich AT phekda DOT freeserve DOT co DOT uk>
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 <djgpp-workers AT delorie DOT com>
Subject: DJGPP and the Large File Summit (LFS)
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/ ]

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019