Re: [boost] posix_time::time_from_string() assertion failed due to bad input format

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-11-23 11:27:18

On Tue, 23 Nov 2004 19:01:45 +0300 (MSK), Alexander Konovalenko wrote
> boost::posix_time::time_from_string() terminates the program due to a
> failed assertion on certain inputs.
> 
> Boost version used: 1.31.0. Compiler used: GCC 3.3.4. (All the tools 
> come from pre-built Debian GNU/Linux packages.) I didn't find a fix 
> for this problem in the latest change log.
> 
> Running the attached test program (see the source) gives the 
> following output:
> 
> date_format_bug_demo: /usr/include/boost/token_iterator.hpp:59: 
> const Type& boost::token_iterator<TokenizerFunc, Iterator, 
> Type>::dereference() const [with TokenizerFunc = 
> boost::char_delimiters_separator<char, std::char_traits<char> >, 
> Iterator = __gnu_cxx::__normal_iterator<const char*, 
> std::basic_string<char, std::char_traits<char>, std::allocator<char>
> > >, Type = std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >]: Assertion `valid_' failed.
> Aborted
> 
> I expected it to throw some descendant of a standard exception 
> instead. Is it indeed the accepted policy in the Date_time library 

Yes, that is what should happen.  Sometimes you can get a lexical_cast 
exception, but that is also std::exception derived. Not sure you can tell 
that this isn't the cause of the abort from this program, however, since you 
don't handle the exception and the compiler knows that.  I'd add a try/catch 
and see what happens.

> to always handle invalid input data by throwing an appropriate 
> exception?  Or are there cases where the input is intentionally 
> assumed to be correct and is thus left unchecked?

I'm actually mildly suprised that that particular format isn't accepted.  My 
guess is that if you add seconds onto the duration it will work. In general, 
date-time will accept any 'delimiter' char between various elements of a 
date including spaces.

BTW, there is a major rewrite of I/O that will be in 1.33 that will allow 
you to define format strings for parsing and output via a new facet.

HTH,

Jeff