[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: Notes when applying IO channel patch
From: Owen Taylor <otaylor () redhat ! com>
Date: 2001-06-30 23:18:01
[Download RAW message or body]
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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic