Hi Commoncpp developer,
Playing around commoncpp 1.6.3 code, I met some behavior under following scenario, which I believe as buggy: 1. Peer A and peer B enter a tcp session 2. A sends some contents to B; if no error is reported (tcp subsystem agree to take over whatever needs to be done to deliver), A closes and exit 3. meanwhile, in a loop, peer B receive byte streams through the TCPStream::read, after which follows a call of TCPStream::gcount() to know how many bytes the previous read() has read in - a exit condition for the loop is gcound() returns 0, indicating tcp stream has nothing to read and should be closed to release this tcp resource. Here comes the bug: the last TCPStrteam::read() actually reads some bytes before its underlying (socket) read returns 0. The 0 return value would immediately call clear(ios::failbit | rdstate() ) (line 2911, src/csocket.cpp, commoncpp-1.6.3), which in turn resets gcount internal data structure _M_gcount to 0, causing the subsequent TCPStream::gcount() returns the incorrect 0. For a socket read to return 0 is quite normal and legitimate when the peer send FIN and enters the so-called half-close state. TCPStream::read() actually reads correctly all the byte stream that might be queued, but the TCPStream::gcount returning 0 subsequently is definitely conflicting what is expected from a read/gcound with an istream object. Hope this description serves its purpose well. Regards, Howell Chen
_______________________________________________ Bug-commoncpp mailing list Bug-commoncpp@gnu.org http://lists.gnu.org/mailman/listinfo/bug-commoncpp
