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
the
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, AFAIK.)
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. ... #else #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 ... #endif 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. Thanks, --Beman