[serialization] typo in basic_binary_iprimitive::load_binary
Hello, File boost/archive/basic_binary_iprimitive.hpp contains two typos in the body of basic_binary_iprimitive::load_binary function definition. The first typo is in line 163: std::streamsize s = count / sizeof(Elem); std::streamsize scount = m_sb.sgetn( static_cast<Elem *>(address), s ); if(count != static_cast<std::size_t>(s)) // line 163 Should be instead: std::streamsize s = count / sizeof(Elem); std::streamsize scount = m_sb.sgetn( static_cast<Elem *>(address), s ); if(scount != static_cast<std::size_t>(s)) // line 163 And the second typo is in line 174: Elem t; scount = m_sb.sgetn(& t, 1); if(count != 1) // line 174 Should be instead: Elem t; scount = m_sb.sgetn(& t, 1); if(scount != 1) -- Vyacheslav E. Andrejev System Architect, Optech International, Inc. E-mail: mortituris@mail.ru
Vyacheslav E. Andrejev wrote:
Hello,
File boost/archive/basic_binary_iprimitive.hpp contains two typos in the body of basic_binary_iprimitive::load_binary function definition.
Very sharp eyes!!! - thanks for spotting this. I've made the change on my local machine so it will show up the next time I check in to the HEAD. Robert Ramey
At 8:20 AM -0800 2/21/07, Robert Ramey wrote:
Vyacheslav E. Andrejev wrote:
Hello,
File boost/archive/basic_binary_iprimitive.hpp contains two typos in the body of basic_binary_iprimitive::load_binary function definition.
Very sharp eyes!!! - thanks for spotting this. I've made the change on my local machine so it will show up the next time I check in to the HEAD.
Robert Ramey
Note that this bug is also present on the RC_1_34 branch. I'm not sure what the ramifications of it are, so not sure whether it is worth fixing for the release. I'm ok with being conservative and patching locally when we upgrade if that turns out to be needed, but if a large number of users are going to need to do that then it probably is worth fixing on the release branch. The changes involved certainly look pretty safe and unlikely to cause regressions.
Note that this bug is also present on the RC_1_34 branch. I'm not sure what the ramifications of it are, so not sure whether it is worth fixing for the release.
Its not. It would only be an issue in the case where one created a binary_?archive with a wide char interface. I don't expect anyone to do that and in fact we don't even test this variation. The reason that this is template based on character type are: a) I started with a copy of text_?archive b) Although I can't see any use for a binary_archive based on wchar_t, I'm not sure someone else might find a need for it. So, I'm applying the patch - but I don't think anyone has or every well come up upon this problem. Robert Ramey
At 11:50 AM -0800 2/21/07, Robert Ramey wrote:
It would only be an issue in the case where one created a binary_?archive with a wide char interface.
Ah! That would be why I was having a hard time figuring out what that template parameter was doing. I agree, leave the RC branch alone.
Hello Robert, RR> It would only be an issue in the case where one created a RR> binary_?archive with a wide char interface. This is wrong. I had a serious issue in my project until I had fixed the typos. Obviously, the implication of these typos is that there will be no exception thrown at the end of the input stream. Therefore there is no way to detect the end of the wrapping archive. There was a way in the previous boost release, where istream::read was used instead of basic_streambuf::sgetn used now, because istream::read itself can issue std::ios_base::failure exception. But this is not the case in the current implementation, and no exception is thrown at the end of input stream. So, if you can rely on my experience, please, believe me that these typos can cause a serious headache. And it is undoubtedly worth to fix it for the release. RR> So, I'm applying the patch - but I don't think anyone has or every RR> well come up upon this problem. Thank you for the patch. I did come up upon. Regards. Slava. -- Vyacheslav E. Andrejev System Architect, Optech International, Inc. E-mail: mortituris@mail.ru
participants (3)
-
Kim Barrett -
Robert Ramey -
Vyacheslav E. Andrejev