Jerry Stuckle <jstucklex@attglobal.net>: Oct 27 05:12PM -0400 On 10/27/2017 10:36 AM, David Brown wrote: > can compete in pissing contests with the other grumpy old right-wing > has-beens. (Yes, I know I sometimes take part in such threads in s.e.d. > - they are on-topic in that group.) LOL, it's pointless when you don't have any facts to support your position. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Oct 27 05:14PM -0400 On 10/27/2017 10:16 AM, bitrex wrote: > who even promises to constrain the power of the executive branch in > theory, rather than expand it in practice. Then I'll believe this "rule > of law" stuff. Wake up. He's in office right now. And maybe while you're at it, you can answer my questions - which you didn't. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
"Öö Tiib" <ootiib@hot.ee>: Oct 27 03:47PM -0700 On Saturday, 28 October 2017 00:14:21 UTC+3, Jerry Stuckle wrote: > > of law" stuff. > Wake up. He's in office right now. And maybe while you're at it, you > can answer my questions - which you didn't. Oh. You mean huge rocket fellow? Making devices that drive humans to extinction has never violated any laws. Like any other quality engineering work does not violate any laws. Using those does not also violate any laws. None of international treaties bans usage of killer robots and so everybody are now making those in hurry. Killer robots will assure our extinction as species autonomously, without need of any human to press any buttons. No law will be violated. |
Christopher Pisz <christopherpisz@gmail.com>: Oct 27 12:42PM -0700 When I lose connection I try to reconnect in a loop forever and once I reconnect I send a log in message to the component I am connection to. That component then sends back a log in response that looks like "MyResponse" The initial connection works fine. After I reconnect, however, I get garbage before the expected message, that looks like: "ýMyMessage" After googling this. I see many questions on Stack Overflow about the boost::asio::streambuf that is used for async sockets in boost::asio. I have followed the advice there and called consume. I have also used wireshark to make sure that the garbage character is not being sent and it is not. After much debugging, it appears as though the calls to consume are injecting a character rather than clearing out all characters. Here is a minimal example: #include <boost/asio.hpp> #include <iostream> #include <sstream> #include <string> int main() { boost::asio::streambuf buffer; std::cout << "buffer size " << buffer.size() << std::endl; buffer.consume(std::numeric_limits<size_t>::max()); std::cout << "buffer size " << buffer.size() << std::endl; std::istream is(&buffer); std::string contents; is >> contents; std::cout << "Contents: " << contents << std::endl; std::cout << "buffer size " << buffer.size() << std::endl; return 0; } Output: buffer size 0 buffer size 1 Contents: ² buffer size 0 If I do not use consume, I get some of the message, previous to disconnect, before the first message after reconnection, in my server code. If I do use consume, I get a garbage character. |
"Öö Tiib" <ootiib@hot.ee>: Oct 27 01:30PM -0700 On Friday, 27 October 2017 22:42:28 UTC+3, Christopher Pisz wrote: > buffer size 0 > If I do not use consume, I get some of the message, previous to disconnect, before the first message after reconnection, in my server code. > If I do use consume, I get a garbage character. It smells (no time to try) that the issue in posted code is because you attempt consuming std::numeric_limits<size_t>::max() bytes. It is something like 18446744073709551615 bytes on most platforms and that is way more data than we have in internet. Perhaps try consuming somewhat less and see what happens? If it is defect of boost ... then debug it out and send them a patch. ;) |
Christopher Pisz <christopherpisz@gmail.com>: Oct 27 01:37PM -0700 On Friday, October 27, 2017 at 3:30:29 PM UTC-5, Öö Tiib wrote: > way more data than we have in internet. Perhaps try consuming somewhat > less and see what happens? If it is defect of boost ... then debug it > out and send them a patch. ;) I've tried other values as well, with the same results. I could not debug boost code if my life depended on it. I require comments, well named variables that are self describing, and the like... I do like using it though :) Until something like this happens. |
"Öö Tiib" <ootiib@hot.ee>: Oct 27 01:42PM -0700 On Friday, 27 October 2017 23:37:11 UTC+3, Christopher Pisz wrote: > I've tried other values as well, with the same results. > I could not debug boost code if my life depended on it. I require comments, well named variables that are self describing, and the like... > I do like using it though :) Until something like this happens. OK, took time, tried. I can't reproduce with certain other values. Demo here: http://coliru.stacked-crooked.com/a/82265415d2ada82b |
Christopher Pisz <christopherpisz@gmail.com>: Oct 27 01:48PM -0700 On Friday, October 27, 2017 at 3:42:55 PM UTC-5, Öö Tiib wrote: > OK, took time, tried. I can't reproduce with certain other values. > Demo here: > http://coliru.stacked-crooked.com/a/82265415d2ada82b buffer.max_size() results are the same. I did get a good result with 777, however. Very wierd. |
"Öö Tiib" <ootiib@hot.ee>: Oct 27 01:53PM -0700 On Friday, 27 October 2017 23:48:21 UTC+3, Christopher Pisz wrote: > > http://coliru.stacked-crooked.com/a/82265415d2ada82b > buffer.max_size() results are the same. > I did get a good result with 777, however. Very wierd. I suspect that std::numeric_limits<size_t>::max() - buffer.max_size() == 0 So it is not less like I suggested. ;) |
Christopher Pisz <christopherpisz@gmail.com>: Oct 27 01:58PM -0700 On Friday, October 27, 2017 at 3:53:21 PM UTC-5, Öö Tiib wrote: > > I did get a good result with 777, however. Very wierd. > I suspect that std::numeric_limits<size_t>::max() - buffer.max_size() == 0 > So it is not less like I suggested. ;) Fair enough. Though it should work. Looks like a boost bug to me. thanks! |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment