From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-01-31 17:36:58
At 12:44 PM 1/31/2004, Jens Maurer wrote:
>Beman Dawes wrote:
>> On POSIX compliant 32-bit systems, is there any reliable way to find
>> size of a file?
>First, POSIX only had stat(), which is limited to 32 bits, as you
>found out. When files got large enough that this wasn't a good
>assumption any more even on 32bit systems, a new interface was
>introduced: stat64() which has, for example, a 64bit
>(Btw, Linux 2.6 supports up to 16 TB file sizes on 32bit machines,
>Of course, 64bit environments have their regular stat()
>use 64bit stat::st_size.
>You get stat64() by #define _LARGEFILE64_SOURCE .
>You get stat() to use a 64bit stat::st_size even on 32bit
>environments by #define _FILE_OFFSET_BITS=64 .
So it sounds like Boost.Filesystem could have an implementation-defined
type, say "file_offset_type", which would be either long or long long. Then
Boost.Filesystem would provide:
file_offset_type size( const path & );
The implementation would go something like this:
#if defined( BOOST_WINDOWS )
// use the Windows native API; file_offset_type is long long.
#define _FILE_OFFSET_BITS 64 // this may or may not do anything
// use stat(); file_offset_type is same as off_t,
// which may be 32-bits on 32-bit platforms which don't
// respond to _FILE_OFFSET_BITS
Does that make sense? It will take some configuration work to know whether
to typedef file_offset_type to long or long long; we don't want to expose
platform header files in the Boost header. Need to think about that.
>Both options require reasonably recent Unix systems.
>The latter option may impede binary compatibility if some
>modules are compiled with the #define and others aren't,
>because the perceived "struct stat" size will be different.
If the use of "struct stat" is hidden within a Boost.Filesystem
implementation file, will that be a problem? I wouldn't think so.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk