[serialization] possible bug writing to text_oarchive
Hi, I use boost::serialization a lot to marshall c++ structures to be sent to a socket, like this: void send_update(ostream &out, const data_t &data) { { text_oarchive oa(out); oa << data; } out << "220 OK" << endl; } The problem is that text_oarchive doesn't append a blank character to denote the end of its data. If the last member sent to the oarchive is an unsigned 123 number, in this example the data sent would be ... (begining of data)... 123220 OK<CR> When processing this with text_iarchive, the last member gets the value 123220, instead of 123. By appending an space (or \n) to the end, in ~text_oarchive, this problem is solved. Another worst problem is if the receiver uses blocking socket connection (and no 220 OK is sent). After reading the last digit (3), it would wait for the next one, which wouldn't arrive, blocking the connection. By having an space after the last digit, it would know that the data stream has ended and it wouldn't block anymore. I've wasted the whole day figuring why my application was blocking :( Thanks, Rodolfo Lima _______________________________________________________ Yahoo! Acesso Gr�tis - Internet r�pida e gr�tis. Instale o discador agora! http://br.acesso.yahoo.com
This was reported and is fixed in the next release. Robert Ramey rodolfo@rodsoft.org wrote:
Hi, I use boost::serialization a lot to marshall c++ structures to be sent to a socket, like this:
void send_update(ostream &out, const data_t &data) { { text_oarchive oa(out); oa << data; } out << "220 OK" << endl; }
The problem is that text_oarchive doesn't append a blank character to denote the end of its data. If the last member sent to the oarchive is an unsigned 123 number, in this example the data sent would be
... (begining of data)... 123220 OK<CR>
When processing this with text_iarchive, the last member gets the value 123220, instead of 123.
By appending an space (or \n) to the end, in ~text_oarchive, this problem is solved. Another worst problem is if the receiver uses blocking socket connection (and no 220 OK is sent). After reading the last digit (3), it would wait for the next one, which wouldn't arrive, blocking the connection. By having an space after the last digit, it would know that the data stream has ended and it wouldn't block anymore.
I've wasted the whole day figuring why my application was blocking :(
Thanks, Rodolfo Lima
_______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Mar 23, 2006 at 08:12:35PM -0800, Robert Ramey wrote:
This was reported and is fixed in the next release.
Oh, ok, sorry. But I've also noticed that when you load a primitive, you don't check if the stream is still valid AFTER loading. You do before. This way, if the loading fails, the variable is left with bogus values. If it is the size of an string, a high bogus value (but not so high...) would make it reserve too much memory. I think that checking after is better. Thanks, Rodolfo Lima _______________________________________________________ Novo Yahoo! Messenger com voz: Instale agora e fa�a liga��es de gra�a. http://br.messenger.yahoo.com/
participants (2)
-
Robert Ramey -
rodolfo＠rodsoft.org