[gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data().

[Nikos Mavrogiannopoulos]

On Tue, 2014-12-16 at 18:18 +0200, Jaak Ristioja wrote:
> ---
>  lib/gnutls_str.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Would you like to send a DCO [0] and rebase the patches
on master?

[0]. http://www.gnutls.org/devel.html


> > However, I tried your test case with 3.3.11 and there hasn't been
> any
> > issue. Have you tried the latest gnutls versions?
> 
> I tried the *.c files I sent earlier with GnuTLS 3.3.10 and got the
> INT32_MIN issue.

That is strange. Could it be that the applications (or one of them) were
linked to an older version of the library? Are you using a 32-bit system
or 64-bit? I cannot reproduce it on my x86-64.

> > The buffer has the ability for quite consumption of its data (see
> > buffer_pop_datum), but when appending to a buffer you most probably
> want
> > to re-use any space that was consumed by buffer_pop_datum(). Said
> that,
> > if you think there can be optimizations please suggest them.
> 
> Please correct me if I have misunderstood this. So the buffer is a
> FIFO
> of bytes, which only reallocates the storage if full. The allocd field
> points to the start of the (re)allocated memory, the data field points
> to the data not yet popped, the max_length field is the size of the
> allocation, and the length field is the size of the data still in the
> buffer which has not yet been popped.

Correct.


> I just submitted a small set of patches to optimize the
> _gnutls_buffer_append_data() function a little. Please note, however,
> that there are still at least 3 potential problems in that function:
> 
> 1) Setting tot_len may overflow the size_t destination type:
>   size_t const tot_len = data_size + dest->length;
> 2) Setting new_len may overflow the size_t destination type:
>   size_t const new_len =
>     MAX(data_size, MIN_CHUNK) + MAX(dest->max_length,
>                     MIN_CHUNK);

Do you use such large buffers? These functions were never intended to be
used with buffers even nearly close to 2^32. But returning an error code
when the buffers reach some high limit should be more appropriate
indeed.

regards,
Nikos