Jeff Garland wrote:
So, in short, there's a bug in the new code that I'm going to fix, but it isn't causing the current regression failures you're seeing.
I know. I was just trying to see what will happen with date_time library tests on the two HP platforms -- Tru64 and HP-UX -- when you get rid of the old I/O code conditionlized with USE_DATE_TIME_PRE_1_33_FACET_IO macro. I think, that after the fix in date_facet.hpp, Tru64 will be fine: the tests compile cleanly without the USE_DATE_TIME_PRE_1_33_FACET_IO macro defined except teststreams.cpp which is missing: #include "boost/date_time/gregorian/greg_facet.hpp" Currently, teststreams.cpp does not compile without the USE_DATE_TIME_PRE_1_33_FACET_IO macro defined not only on Tru64 with cxx, but, also, on Linux with either Intel compiler or g++. When I add missing '#include', it compiles cleanly on all of the above. There is a general problem with date_time library tests HP-UX: the tests fail to compile with the same compilation error. I'm looking into it. Boris Gubenko ----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Thursday, June 15, 2006 11:48 AM Subject: Re: [boost] [date_time] a possible bug in date_facet.hpp
Boris Gubenko wrote:
Three date_time library tests: testgreg_wstream, testparse_date and teststreams -- are marked as failures on Tru64 because of the bug in
...details snipped...
So, is it a bug in date_facet.hpp or I'm missing something? Or, may be, a bad test?
Hi Boris --
Good catch on this, it is indeed a bug in the new facet code. The thing is, it never shows up in the regression tests because those wide stream tests are run using the old date-time i/o code -- I think we must have forgot to include both variations. Anyway, if you look at the Jamfile you'll see it uses the following define:
<define>USE_DATE_TIME_PRE_1_33_FACET_IO
when compiling those tests (or alternatively from libs/date_time/test you can say bjam --verbose-test testgreg_wstream and the flags will be set for you).
So actually, whatever errors that are showing up in these regression tests aren't coming out of the code that you are pointing out. There's a set of alternative i/o code that was developed is contained mostly in xyz_limited.hpp files that should be in effect for these particular tests.
So, in short, there's a bug in the new code that I'm going to fix, but it isn't causing the current regression failures you're seeing. BTW, this is one of the reason I want to rid myself of maintaining these old compilers -- the i/o code is tricky enough and hard enough without having 2 versions with different levels of ability.
Jeff