Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3BC33F16.8E19850E@phekda.freeserve.co.uk> Date: Tue, 09 Oct 2001 19:16:54 +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: Resend: DJGPP and files > 2GB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. The bug in 'ls' a couple of months ago highlighted some problems with the handling of files > 2GB in size. I've been looking at the Single Unix Specification (SUSv2) and the Large File Summit: SUSv2: http://www.opengroup.org/ LFS: http://ftp.sas.com/standards/large.file/ An example of the problem is the handling of the st_size member of the stat structure. st_size is an off_t. This means that the maximum size that can be represented is 2GB - 1. Currently stat will return a large negative number, since off_t is signed (which caused ls to output a bogus size). If st_size cannot represent the file's size, stat is supposed to return -1 and set errno to EOVERFLOW. I don't think the library's current behaviour is good - who knows what effect silently returning bogus sizes for files >= 2GB will have? There seem to be several ways of addressing the problem: 1. Grow off_t to a 64-bit type (i.e. signed long long). Clearly this will break backward compatibility, but it may be the easiest solution for the lazy programmer. ;) 2. Return EOVERFLOW when off_t can't represent the size. Since support for files >= 2GB was added to DJGPP 2.04, we need to add functions that allow people to use this support, otherwise there's no point having it. There are two ways of doing this: 2a) The transitional API - *64 versions of current functions, e.g. stat64. This and the traditional API can be used on the same descriptors. 2b) Large file functions and large off_t that are enabled when _LARGEFILE_SOURCE is defined before including headers. 2a and 2b are not mutally exclusive. 2a doesn't appear to be used by Fileutils - perhaps the transition has already occurred or people avoided the transitional API, because it was clearly a temporary hack? 2b seems like the best solution, but how would we implement linking to different versions of stat? Via #defines seems like the natural way, but is this acceptable? What do people think about adding LFS support to DJGPP? I think we should add the checking for overflowing of off_t right now. I'm willing to look at this and code it up. 2b may take longer. Thanks, bye, Rich -- Richard Dawe http://www.phekda.freeserve.co.uk/richdawe/