After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 645139 - Cannot call a C function returning a zero-terminated GStrv
Cannot call a C function returning a zero-terminated GStrv
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2011-03-18 14:17 UTC by Alban Crequy
Modified: 2011-05-26 18:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alban Crequy 2011-03-18 14:17:59 UTC
A C function returns "const GStrv" with the following annotation:
 * Returns: (transfer none) (array zero-terminated=1) (element-type char*): 
 */
const GStrv
sw_item_get_value_all (SwItem  *item, const gchar *key)

The generated .gir file contains:
        <return-value transfer-ownership="none">
          <array c:type="GStrv">
            <type name="utf8"/>
          </array>
        </return-value>

The generated .vapi file contains:
  public unowned string[] get_value_all (string key);

When I call the C function from vala code, the generated C code does not compile:
        _tmp12_ = sw_item_get_value_all (item, "url", &_tmp11_);

swf-persona.c:446: error: too many arguments to function ‘sw_item_get_value_all’

The additional argument "_tmp11_" is used as the size of the returned array.

Expected outcome:
 - GStrv should be automatically detected as a zero-terminated array, even without annotation.
 - If not automatically detected, the annotation zero-terminated=1 should be added in the vapi/gir file.
 - The generated C code should not have extra arguments.
 - The generated C code should compile.
Comment 1 Luca Bruno 2011-03-20 00:19:53 UTC
Thanks for your report.
I found these types of gstrv in a single gir:
<type name="utf8" c:type="gchar**"/>
<type name="GObject.Strv"/>
<array c:type="GStrv"><type name="utf8"/></array>
<array><type name="utf8"/></array>

I'm tempted to reassign this to gobject introspection, just to understand which annotation is the correct one.
Comment 2 Colin Walters 2011-04-07 20:28:43 UTC
We special case GStrv in the scanner to be <array c:type="GStrv"><type name="utf8"/></array>.  Can you try dropping the (array) and (element-type) annotations?
Comment 3 Alban Crequy 2011-04-08 15:19:08 UTC
(In reply to comment #2)
> We special case GStrv in the scanner to be <array c:type="GStrv"><type
> name="utf8"/></array>.  Can you try dropping the (array) and (element-type)
> annotations?

When I drop the (array) and (element-type) annotations, it is still generate the same XML <array c:type="GStrv"><type name="utf8"/></array>.

But valac still generate C code which does not compile.
Comment 4 Luca Bruno 2011-05-26 18:46:56 UTC
commit d99a06073f028e98401323ac0ac57003a82159dc
Author: Luca Bruno <lucabru@src.gnome.org>
Date:   Thu May 26 20:41:28 2011 +0200

    girparser: Special case array of ctype GStrv as a null terminated array
    
    Fixes bug 645139.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.