Re: Notes when applying IO channel patch

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp@redhat.com> writes:

> Owen Taylor <otaylor@redhat.com> writes:
> > Tim Janik <timj@gtk.org> writes:
> > 
> > > On 30 Jun 2001, Owen Taylor wrote:
> > > 
> > > > * I exposed GString->alloc, since I think it is necessary for 
> > > >   efficient use of a GString as a buffer. Otherwise, you are
> > > >   unnecessarily often using smaller buffer sizes than the 
> > > >   space you have available.
> > > 
> > > if we do that, can we please rename this to something more elaborate,
> > > e.g. n_bytes, buffer_size or simply n_alloced.
> > 
> > I went with allocated_len.
> > 
> 
> How do you use this field? Doesn't GString feel free to put nul bytes
> on top of any position > str->len? Or are you supposed to write to
> str->len?

The way I'd expect it to be used would be somthing like:

 gsize old_len = str->len;
 g_string_set_length (string, str->allocated_len - 1);
 count = read (string, buffer, buffer->str + old_len, buffer->len - old_len);
 g_string_set_length (string, old_len + count); 

Is it a bit hackish? Yes. But I think in general it works out quite 
well in the GIOChannel code to use GString for buffers, and
if you don't have access to str->allocated_len, then you end
up using artificially small buffers.

It would actually work with the way GString is written currently
to do:

 count = read (string, buffer, buffer->str + buffer->len,
               buffer->allocated_len - old_len - 1);
 g_string_set_length (string, buffer->len + count); 

Which looks nicer, but I don't know if we want to guarantee that
will work. 

Regards,
                                        Owen