|
|
Boost Testing : |
From: Jonathan Turkanis (turkanis_at_[hidden])
Date: 2008-01-11 18:04:36
Christopher Cambly wrote:
>> Jonathan Turnkanis_at_[hidden] wrote on 09/01/2008 06:15:49 PM:
>>> To close out this thread: it looks like fpost_t and streamoff are both
>>> 32-bit on this platform, so I won't be able to fix the problem; I've
>>> marked it up as an expected failure.
>>>
>> Is the real question: how do I enable large file support on AIX?
>> fpos_t and streamoff are long by default, but if you add the compiler
>> options "-qlonglong -D_LARGE_FILES" it will enable support for large
> files
>> and fpos_t and streamoff become long long.
>>
>>
>
> I did a little more experimentation. The test works correctly when
> address-model=64 (with a patch to vacpp.jam for the vacpp.archive action).
>
> When I just add -qlonglong -D_LARGE_FILES, fpos_t and streamoff are now 8
> bytes, but the test still fails with the following:
> ****************************************
> * sizeof(fpos_t) = 8
> * sizeof(streamoff) = 8
> * sizeof(stream_offset) = 8
> ****************************************
> stream_offset_64bit_test.cpp(59): fatal error in
> "stream_offset_64bit_test": off !=
> position_to_offset(offset_to_position(off)) failed for (off >> 32) ==
> 0xffffffe7 and (off & 0xFFFFFFFF) == 0x3fd180
>
> I am not all that familiar with what this particular test is testing.
> Adding large file support allows 32 bit programs to access files > 2G.
> Address-model=64 makes this a true 64 bit application.
stream_offset_64bit_test.cpp tests the Boost.Iostreams functions
offset_to_position() and position_to_offset(), which translate between
stream offsets (integers) and stream positions (class types that store
offsets plus code conversion states).
For most platforms, the functions just cast between types, but for
platforms that use the Dinkumware fpos template, including the Visual
Age default standard library, the implementation (provided by Gareth
Sylvester-Bradley) uses some Dinkumware-specific functions and macros
and a little arithmetic. The test does not perform any filesystem access.
My goal is to make the test pass whenever possible, regardless of the
compiler flags, since those should be determined by the end user and not
the library author. When fpos_t is 4 bytes, there's nothing I can do to
make the test pass. I'm encouraged that it passes with address-model=64,
but it concerns me that it doesn't work with -qlonglong -D_LARGE_FILES,
when all the relevant types have size 8.
I think the problem might be that the compiler is picking up the wrong
branch of code in fpos_t_to_offset (boost/iostreams/positioning.hpp:80).
I have checked in a possible fix; would you mind testing it with the
three sets of compiler flags and reporting the results?
--
While we're on the subject of compiler flags for large file support,
there's another part of the Iostreams library that I have attempted to
configure for IBM. I've read the documentation, but it would be great to
have input from an expert. In the header
boost/iostreams/detail/config/rtl.hpp, I attempt to determine whether to
use plain POSIX file descriptor functions or the xxx64 versions provided
by some systems.
The goal is to use the plain versions whenever they support 64-bit file
offsets, and to switch to the xxx64 variants if they are available and
the only way to access large files.
Here's the code I've come up with so far by reading the GNU and and IBM
documentation:
# if defined(_LARGEFILE64_SOURCE) && \
(!defined(_FILE_OFFSET_BITS) || _FILE_OFFSET_BITS != 64) || \
defined(__IBMCPP__) && !defined(__64BIT__) &&
!defined(_LARGE_FILE) || \
defined(BOOST_IOSTREAMS_HAS_LSEEK64)
/**/
# define BOOST_IOSTREAMS_FD_SEEK lseek64 // Some GCC and IBM
# define BOOST_IOSTREAMS_FD_TRUNCATE ftruncate64
# define BOOST_IOSTREAMS_FD_STAT stat64
# define BOOST_IOSTREAMS_FD_OFFSET off64_t
# else // Cygwin, Darwin, ...
# define BOOST_IOSTREAMS_FD_SEEK lseek
# define BOOST_IOSTREAMS_FD_TRUNCATE ftruncate
# define BOOST_IOSTREAMS_FD_STAT stat
# define BOOST_IOSTREAMS_FD_OFFSET off_t
# endif
Could you let me know whether this is correct, at least as far as AIX is
concerned? One thing I notice right away is that the IBM docs I've read
describe the flag _LARGE_FILE, while above you used _LARGE_FILES, with a
trailing 'S'. I'm guessing the docs are wrong here. (The manual I used
was "Developing and Porting C and C++ Applications on AIX", by Matsubara
et al.)
Thanks for your help,
--
Jonathan Turkanis
CodeRage
http://www.coderage.com