Re: G_TYPE_<unterminated-string> (was: Re: Status of 2.0 API freeze bugs)

[Tim Janik <timj gtk org>]

On 3 Apr 2001, Owen Taylor wrote:

> > 2) the argument order, which is (guint8 *bytes, guint n_bytes) in your
> >    patch
> > 
> > for (1), i need to extend glib-genmarshal.c to generically deal with in value
> > types that get passed as multiple args (marshalling of out value types with multiple
> > args are not going to be supported for 2.0).
> > 
> > for (2), we definitely need to change that to (guint n_bytes, guint8 *bytes),
> > and people have to be aware of this as these args are passed through a varargs
> > interface.
> > 
> > on why the number of elements should be passed as first arg by general
> > convention:
> 
> The _general_ convention on the position of "number of items" is not
> as important to me as the specific convention on strings w. length.
> 
>  g_strndup, g_strncasecmp, g_convert, g_locale_to_utf8,
>  g_string_insert_len, g_unicode_strlen, gtk_text_insert,
>  gtk_editable_insert_text...

well, for g_strndup() it's probably not hard to see why the length
argument got appended with gchar* g_strdup (gchar *str); already being
in place. g_strncasecmp() is another example of 2 strings + 1 length,
additionally it got modelled after strncmp() which i can see taking
precedence for glib.

>  (And of course, ::insert_text, the signal for which we wanted
>  G_TYPE_BYTES to begin with)
> 
>  At least 20-30 more
> 
> Now, you may argue that a lot of this (though not nearly all of this)
> is new API. But in any case, there is darn lot of this in this
> order and I don't see changing it now, even if I was convinced
> that it was right to do so.
> 
> The only exception to the uniform ordering I know of is gtk_widget_path
> and friends, and that is sort of odd for other reasons because the
> length refers to two strings.

i think we should better ask whether it's a good idea in the first place
to reverse the (n_elements, elements) scheme for strings in gtk+, and then
technically, G_TYPE_BYTES is not something storing strings per-se.

it'd be a pity to have G_TYPE_BYTES and G_TYPE_CHARACTERS when they
only differ in the order they expected their length and contents args.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ