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

[Owen Taylor <otaylor redhat com>]

The issue here, for people who have forgotten, is that of the
marshalling of G_TYPE_BYTES, which is a non-NUL terminated string
type, in varargs lists, such as parameters lists for signals.

In the varargs list, this is marshalled as a separate length and pointer.
So, the question comes up, does the pointer preceed or follow the
length. Is it:

 ...
 gchar *bytes,
 gint   n_bytes,
 ...

Or:

 ...
 gchar *n_bytes,
 gint   bytes,
 ...

Before reading further, stop, and consider whether one of these seems
more natural to you? If so, mail me and tell me which one, before
reading further, so as to avoid contamination from my point of view.

Regards,
                                              Owen

===

Discussion and opinion:
 
For arrays in general, we don't have a consistent convention about this
in GTK+, though the majority of functions have followed the elements/n_elements
ordering, from the earliest days of GTK+ until now.

For strings, we are perfectly (or almost perfectly) consistent and
have string/length. This also is the ordering found in the C library
for memcmp, strncpy, etc.

Furthermore, the reason why we wanted G_TYPE_BYTES was for
gtk_editable_insert_text(), which is string followed length. It
cannot be changed without breaking compatibility.  So, if we do
add G_TYPE_BYTES, marshalled as length, string, it is perfectly
useless.

So, I'm strongly in the string/length camp.


The countering argument centers around the idea that a calling a function
with an array/length pair is similar to a varargs list with a count, the 
sole example in GTK+ being gtk_signal_new() and variants:

 gtk_signal_new (..., G_TYPE_NONE, 2, G_TYPE_INT, G_TYPE_FLOAT);

The count here must proceed the elements. I'm not convinced by this
argument:

 * I don't see these varargs functions as being really the same thing
   as an array with a length.

 * We have almost no varargs functions like this, and none of these
   involve marshalled types.

 * We aren't going to be consistently length/string, since we have huge
   numbers of existing functions with the opposite argument. So do we
   need to be consistent with a few varargs functions.