Re: g_string_new_len(const gchar *, GSSIZE) (glib-2.0)
- From: Owen Taylor <otaylor redhat com>
- To: Mark Mielke <mark mark mielke cc>
- Cc: gtk-devel-list gnome org
- Subject: Re: g_string_new_len(const gchar *, GSSIZE) (glib-2.0)
- Date: Sat, 23 Mar 2002 12:08:45 -0500 (EST)
Mark Mielke <mark mark mielke cc> writes:
> If the GString structure uses gsize, why does g_string_new_len() use
> gssize?
>
> Usually this won't present a problem, but I am curious as to why I
> should need to code around this limitation for the case that it
> might actually be a problem.
>
> The same argument applies to g_string_insert_len(), g_string_append_len(),
> and g_string_prepend_len().
>
> Specifically, I am dealing with code that might use a GString to hold
> a very large piece of data, with little range structures to refer to
> pieces of the string. If necessary, I may need to copy the piece of
> the string into its own string in order to perform local
> modifications. g_string_new_len() appears to be the perfect candidate
> for this... except that it uses gssize as an argument.
The convention is that in GLib and GTK+, functions that take string/length
pairs, support -1 for the length to mean "use strlen(str)".
Yes, this limits the amount of text that can be inserted into a string
at one time to half the size of the address space, but, well, if half
the address space is holding the string you are copying from and
half the address space is holding the newly allocated string, that's
the whole address space. :-)
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]