If the result is non-NULL it must be freed with g_strfreev().
In am not sure how the GIR file tells me that the result can be NULL. In my binding generator script I do a test with
if gCallableInfoMayReturnNull(minfo):
That test should give TRUE for gtk_selection_data_get_uris() but it seems that I get FALSE instead.
Indeed in the GIR file I can not find a hint that return value can be NULL:
<method name="get_uris"
c:identifier="gtk_selection_data_get_uris"
version="2.6">
<doc xml:space="preserve"
filename="gtk+-3.24.30/gtk/gtkselection.c"
line="1887">Gets the contents of the selection data as array of URIs.</doc>
<source-position filename="gtk+-3.24.30/gtk/gtkselection.h"
line="233"/>
<return-value transfer-ownership="full">
<doc xml:space="preserve"
filename="gtk+-3.24.30/gtk/gtkselection.c"
line="1893">if
the selection data contains a list of
URIs, a newly allocated %NULL-terminated string array
containing the URIs, otherwise %NULL. If the result is
non-%NULL it must be freed with g_strfreev().</doc>
<array c:type="gchar**">
<type name="utf8"/>
</array>
</return-value>
Well, may be a bug in the GIR file. I just compared with gtk_clipboard_wait_for_uris() for which the Nim bindings are fine:
<method name="wait_for_uris"
c:identifier="gtk_clipboard_wait_for_uris"
version="2.14">
<doc xml:space="preserve"
filename="gtk+-3.24.30/gtk/gtkclipboard.c"
line="1637">Requests the contents of the clipboard as URIs. This function waits
for the data to be received using the main loop, so events,
timeouts, etc, may be dispatched during the wait.</doc>
<source-position filename="gtk+-3.24.30/gtk/gtkclipboard.h"
line="265"/>
<return-value transfer-ownership="full" nullable="1">
<doc xml:space="preserve"
filename="gtk+-3.24.30/gtk/gtkclipboard.c"
line="1645">
a newly-allocated %NULL-terminated array of strings which must
be freed with g_strfreev(), or %NULL if retrieving the
selection data failed. (This could happen for various reasons,
in particular if the clipboard was empty or if the contents of
the clipboard could not be converted into URI form.)</doc>
<array c:type="gchar**">
<type name="utf8"/>
</array>
</return-value>
So I would guess nullable=“1” is missing for gtk_selection_data_get_uris?
[EDIT]
Actually nullable=“1” seems to be missing for most functions with C type gchar** result. And for C GLib.strfreev simply returns. So I think my Nim bindings have to test always for a NULL result when result is of C type gchar**. Maybe for similar results too, that is pointer to array. So I will have to carefully check whenever I use the test " if gCallableInfoMayReturnNull(minfo):"
This should maybe get a (nullable) annotation for the return value but in my experience that’s used inconsistently for NULL-terminated pointer arrays like this one here: it might be there or not.
In the Rust bindings we treat NULL the same as an empty array (i.e. a valid pointer that points to NULL).
We must treat NULL as an empty array because requesting zero bytes from malloc may return a NULL pointer or a non-NULL pointer. (Aside: I don’t see why the non-NULL pointer must be a valid pointer to something as it can never be dereferenced, there being no valid indices with size zero.)
So if an array can be empty, (nullable) doesn’t tell you anything you didn’t already know. That means an array that can be empty cannot be optional. Note that a null-terminated array is never empty due to the null terminator so can be optional.
In Giraffe Library, the logic for determining whether an array is optional is here.
My point is that gCallableInfoMayReturnNull() should return TRUE. But unfortunately for that we would need the annotation nullable=“1” which is most of the times missing.
That bug was undiscovered in the Nim bindings from the beginning, that is more than five years now, just as we assumed gCallableInfoMayReturnNull() would return TRUE when a NULL pointer can be returned, and as no one got a NULL pointer until yet, so no one complained.
To clarify, I believe you need to determine whether an array can be empty (as the first step of determining whether the array should have an option type) and if it can be (like this return value) then it is nullable regardless of what gCallableInfoMayBeNull() says. For this return value, what are you using gCallableInfoMayBeNull() for?
