[boost] [asio] Mixing streambuf-based async_read and async_read_until

Subject: [boost] [asio] Mixing streambuf-based async_read and async_read_until
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-09-11 04:20:15

I was tracing through some code today (using Boost.Asio 1.53) and 
noticed something that seems a little odd to me.

Given a boost::asio::streambuf that already contains data (typically 
from a previous read), the async_read_until operation will check the 
buffer first to see if it can find the specified delimiter already, and 
will only fetch more data from the stream if it needs to.  It does 
appear to perform at least one async_read_some per async_read_until 
call, but this will be a zero-length-read that will not actually hit the 
network/wherever.  (Could probably be optimised a little further though.)

The async_read operation however will not check the buffer.  While it 
won't destroy any existing data (it just appends) it will still fetch 
additional data from the stream up to the specified completion 
condition, ignoring however much is already in the buffer.

For example, if buf already contains 32 unconsumed bytes then 
async_read(s, buf, transfer_exactly(16), cb) will fetch 16 more bytes 
from the network, leaving 48 bytes in the buffer but only passing 16 to 
the read handler.  Of particular note is that it will wait for those 16 
bytes to be read from the network -- it's not satisfied with the data it 
already has.

The net effect of these behaviours I think is that if you're using 
async_read_until exclusively or async_read exclusively then everything 
will behave fairly normally.  If you are mixing these two operations on 
the same stream then you will either be losing data (if you use separate 
streambufs) or reading more data than you should (if you use the same 
streambuf and don't check outside of ASIO to see if it already contained 
enough data).

Maybe it's just me, but I find it surprising that async_read doesn't 
check if the supplied streambuf already satisfies the completion 
condition, given that async_read_until does and the docs for async_read 
do say that it's allowed to make zero async_read_some calls.

Is this a bug or is it expected behaviour?