GNOME Bugzilla – Bug 529866
no way to specify the type of the array length variable
Last modified: 2010-04-27 09:03:25 UTC
Please describe the problem: Vala assumes the length variable should be a signed integer: my_c_function(char **foo, int length); but some methods may look like this: my_c_function(char **foo, usigned int length); This causes a GCC warning about differing in signedness. Perhaps some .vapi metadata stuff to tell the specific type would be in order. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
An example of this is g_key_file_get_string_list: http://library.gnome.org/devel/glib/stable/glib-Key-value-file-parser.html#g-key-file-get-string-list That uses gsize for the length argument instead of int.
Confirming, that's especially important for out parameters.
A first hacky attempt to fix this bug: http://df3e55588a1c8d51.paste.se/ The patch is just the first attempt that solved it, and is nowhere near usable, but perhaps points to the direction where it should be fixed. It does only handle this case: myfunction(out foo); that translates to for example this: (_tmp2 = (xmmsc_result_get_bin (res, &_tmp1, &_tmp0), data_length1 = &_tmp0), (data = (g_free (data), NULL)), data = _tmp1, _tmp2) Where _tmp1 is the array argument and _tmp0 is the unsigned integer length argument. The .vapi syntax in the above generated example is: public bool get_bin ([CCode(array_length_type="uint")] out uchar[] val); It should ofc handle cases where you pass _out_ the array, and also the case where an array is returned. Anyways, this is a bit over my head I think.. it took me a couple of hours a day for a whole week to get this working, so maybe someone who knows the vala compiler better should have a look at this bug.
Oh.. and in the above comment: (_tmp2 = (xmmsc_result_get_bin (res, &_tmp1, &_tmp0), data_length1 = &_tmp0), (data = (g_free (data), NULL)), data = _tmp1, _tmp2) Should ofc be: (_tmp2 = (xmmsc_result_get_bin (res, &_tmp1, &_tmp0), data_length1 = _tmp0), (data = (g_free (data), NULL)), data = _tmp1, _tmp2) But as I said.. my current impl is completly broken/ugly/crappy or something.
I recently ran into this too: It seems [1] that on sparc64 the gsize/gint mismatch produces compiling *errors*! I initially came here to propose gsize by default, but noticing this existing report I realized that some other C APIs may be using a different size type, so.. I just saw 'array_length_type' in current (vala 0.5.5) glib-2.0.vapi. It seems it not used (yet?) [1] http://code.google.com/p/gtkaml/issues/detail?id=16
*** Bug 588104 has been marked as a duplicate of this bug. ***
Created attachment 140589 [details] [review] Arrays: Add array_length_type annotation to methods Adds support for the array_length_type CCode annotation, which allows methods with array length parameters which are not ints to be declared properly, instead of generating compiler warnings and causing problems on 64-bit systems (usually signed vs. unsigned). Testing would be greatly appreciated. It seems to work here on the Vala files where I use KeyFile's get_*_list() methods.
I should probably also mention that this patch adds the Vala.CType class, as juergbi suggested in IRC, to work around the Vala type limitations.
Created attachment 140702 [details] [review] updated based on juergbi's comments on IRC Moved valactype.vala from vala/ to codegen/, and updated the commit message.
commit 74f2e47906a490f6ae11c058818afc761709a34c Author: Mark Lee <marklee@src.gnome.org> Date: Wed Aug 12 13:53:25 2009 -0700 Arrays: Add array_length_type annotation to methods Adds support for the array_length_type CCode annotation, which allows methods with non-int array length parameters to be declared properly. Fixes possible crashes. Also adds Vala.CType, to work around the temporary variable type limitations. This fix only works with array return types, not with array parameters. Partially fixes bug 529866.
Created attachment 154111 [details] [review] Support array_length_type for fields. I'm not sure what the right way to do this would be for fields. The attached patch simply casts to gint. Even if that's not the right thing to do, this should be a good start since it provides the infrastructure for dealing with array_length_type in Vala.Field.
commit 1803fb26dffce892ca6fbf258970e56bed06b0dd Author: Evan Nemerson <evan@coeus-group.com> Date: Sat Mar 13 18:05:14 2010 +0100 Support array_length_type for fields Fixes part of bug 529866.
*** Bug 601257 has been marked as a duplicate of this bug. ***
Created attachment 157786 [details] [review] support array_length_type for method arguments Not particularly elegant, but it is functional.
commit 7aba22e37c306d3e53a3937827903796e808dd58 Author: Evan Nemerson <evan@coeus-group.com> Date: Fri Apr 2 22:33:11 2010 -0700 Support array_length_type for method parameters Fixes bug 529866.