Boost logo

Boost :

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
>stat64::st_size .
>(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, gregod at, cpdaniel at, john at