On 3.3.2010, at 21.30, Alex Baule wrote:
> But i got some questions about the stream->pos, stream->skip and
position of
> the message and pointer to buffer.
1. Data is read to buffer, and stream->buffer points to it, stream->skip =
0 and stream->pos = number of bytes available in the buffer.
2. i_stream_skip() and i_stream_seek() can go forward by simply increasing
stream->skip. So stream->buffer + stream->skip always points to the
data that i_stream_get_data() returns.
3. Actual seek() implementation typically resets the stream by changing the
offset and setting skip=pos=0.
4. read() can internally do whatever it wants, as long as the result is
consistent. So for example with istream-file the buffer points to a larger
buffer and it tries to avoid memmove()ing data, so it tries to add data at the
end of the buffer and just increase stream->pos. But it can't always do
that, so it then memmove()s the data and sets skip=0.
> The buffer from istream-concat is 4096, i read 4096 from get_stream_data,
> but the result of this read is minor , lets say 4080, but the next read
must
> be from 4096. The "send to client" must be 4080, to send the
correctly data
> decrypted.
>
> My Question is, what the variable used in istream-concat, to send the data
> to client ? I need to update the stream->pos with my data length ??
I'm not really sure what you're asking here.. i_stream_read() for
blocking streams must always read and return at least one byte. There's no
guarantees that it ever returns more than one byte at a time. So if you need to
read more, keep calling i_stream_read() until it has read as much data as you
wanted (i_stream_read_data() does basically that).
istream-concat actually doesn't define buffer's size. It gets the max
buffer size from the parent input streams. But it's still just the max.
buffer size, nothing guarantees that reads can read that much data at a time.