posix_time::time_from_string() assertion failed due to bad input format
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 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? Thanks in advance! -- Alexander
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
On Tue, 23 Nov 2004 19:01:45 +0300 (MSK), Alexander Konovalenko wrote
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.
I forgot to mention explicitly that I had checked that no std::exception-derived exception was thrown. (This can also be deduced from the error message, since an uncaught exception in main() can't cause any assertion inside Boost to fail.) To make sure, you can compile and run the attached file.
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.
Neither (see the attached file). (Note that the formats "2004-Nov-23 15" and "2004-Nov-23 15:00" are accepted by my version of the library and mean the same thing.)
In general, date-time will accept any 'delimiter' char between various elements of a date including spaces.
From a quick look at the source code, it doesn't seem so, but I haven't had time to examine that well. It might be the case when the date is there alone (didn't check that), but it doesn't work badly, as you can see, when using time_from_string() to parse both date and time.
To support my claims, attached is the updated version of the test program. It still fails in my setting with the same error message about a _failed assertion_: date_format_bug_demo2: /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 So I believe this is a bug in the date-time library.
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.
Is it in the CVS already? What's your estimate of the release date? -- Alexander
On Tue, 23 Nov 2004 20:54:32 +0300 (MSK), Alexander Konovalenko wrote
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.
Is it in the CVS already? What's your estimate of the release date?
Much of the code is already in CVS, but the 'interfaces' (eg: operator>> and operator<<) are not hooked up. If all goes well I will check in another round in the next week or so that converts over, but don't expect that it will be ready for prime time for a couple months at least. We have a bunch of stuff for local_time we are trying to wrap up as well... In short you can specify the format for input or output via a string using a format string: "%Y-%b-%d %H:%M:%S%F" for a form like: 2004-Oct-20 19:02:57.000002999 So this will give complete control over input and output. If you look at libs/date_time/gregorian/testformat_date_parser.cpp and libs/date_time/posix_time/testtime_facet.cpp you can see more examples of how the guts of the new design works. Jeff
participants (4)
-
Alexander Konovalenko -
Jeff Garland