Boost Testing :
From: Jonathan Turkanis (turkanis_at_[hidden])
Date: 2008-01-12 15:27:42
Christopher Cambly wrote:
> Jonathan Turnkanis_at_[hidden] wrote on 09/01/2008 06:15:49 PM:
>> 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?
> Here are the results from the 3 variant runs.
> 1) Test case fails when fpos_t is 4 bytes as you expected.
> 2) Test case now passes with -qlonglong -D_LARGE_FILES
> 3) Test case passes with address-model=64
That's great news. Thanks.
>> 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.
>> 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.)
> I am not familiar with that particular document, typically I just use the
> AIX documentation. I can tell you that _LARGE_FILE is incorrect, it is
> _LARGE_FILES with the S. This link may be helpful to you:
> http://tinyurl.com/ys85ss If you search for "large files" there is a
> document called "Writing Programs That Access Large Files" that seems to
> answer some of your questions,
Thanks for the link; that's just what I need.
but I will take a closer look at that code
> next week.
When you do, please look at the most recent trunk, rather than the code
I posted in my last message:
> Chris Cambly
> XL C/C++ Compiler Development
Thanks for your help,
-- Jonathan Turkanis CodeRage http://www.coderage.com