From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-06-19 16:39:30
Jeff Garland wrote:
> So, in short, there's a bug in the new code that I'm going to fix,
> 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
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:
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
----- Original Message -----
From: "Jeff Garland" <jeff_at_[hidden]>
Cc: "Boris Gubenko" <Boris.Gubenko_at_[hidden]>
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:
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk