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

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 3 Apr 2001, Owen Taylor wrote:
> 
> 
> > 50209	gobject glib	Need a G_TYPE_ for non-nul-terminated strings 
> > 
> >  Patch from otaylor needs to be fixed-up / applied by timj
> 
> there are basically two issues i have with that patch.
> 
> 1) the way in wich it special cases G_TYPE_BYTES in glib-genmarshal.c,

This is entirely your business ;-)

> 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...

 (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.

Regards,
                                        Owen