Create boost_1_33_1 boost::archive::text_iarchive with an empty stream
Hi, The following code does not throw archive_exception always: std::stringstream ss; boost::archive::text_iarchive ia(ss); The archive_exception is thrown always on VC++2005/Windows while on GCC3.2.2/Redhat8 and GCC3.4.6/CentOS a std::length_error: basic_string::resize is thrown sometimes. That means the constructor tries to resize some string with value > basic_string.max_size(). The GCC defines the max_size() to be only about a quarter of the max length the allocator can get. That explains why that exception happens to be raised on GCC. A search of the source code lead me to the overloaded methods 'load' of text_iarchive_impl<Archive>. They look suspicious because do not check the input stream state before using the string size just loaded. The local variable is not initialized nor loaded, so it contains some arbitrary value! In the method load(std::string&) that might cause std::length_error while in load(char *s) - even program crash. The code in the next Boost versions does not seem to be changed. Has anyone encountered such behavior? I've not found that bug reported. Thanks in advance, Gancho
Note that this code Gancho Manev wrote:
Hi,
The following code does not throw archive_exception always:
std::stringstream ss; boost::archive::text_iarchive ia(ss);
Note that the above code is not correct usage of the library and shuold through some some sort of error or exception. Robert Ramey
Hi,
The following code does not throw archive_exception always:
std::stringstream ss; boost::archive::text_iarchive ia(ss);
Note that the above code is not correct usage of the library and shuold through some some sort of error or exception.
I haven't found any line in the documentation that puts a precondition on the stream. What are the preconditions though? Even the stream content is valid there is always a possibility of failure when read. The text_iarchive constructor does not check that leaving a big chance of unexpected exception or even program crash. Thanks, Gancho Manev
participants (2)
-
Gancho Manev
-
Robert Ramey