Hello Araq,
you may have seen Nodrigos trouble with the GTK3 wrapper...
So I have done this minimal test -- box is Linux AMD64, Nim 0.10.3
$ cat tc.c
#include<stdio.h>
int main() {
printf("%ld\n", sizeof(64));
return 0;
}
$ ./a.out
4
$ cat test.nim
import gtk3, glib, gobject
var ls: gtk3.ListStore
echo sizeof(GType)
ls = gtk3.list_store_new(2, GType(64), GType(64))
$ ./test
8
$ grep "64, 64" nimcache/test.c
ls_268005 = Dl_190658(((int) 2), 64, 64);
I don't think that this can work really fine. C size of int literal 64 is 4, size of GType is 8, but generated C proc gets plain int literal.
GTK3 proc uses varargs, may that be a problem?
proc list_store_new*(n_columns: gint): ListStore {.varargs,
importc: "gtk_list_store_new", libgtk.}
GType is defined in gobject.nim like this, but that should not matter:
# when GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG or not defined(cplusplus):
when sizeof(csize) != sizeof(clong) or not defined(cpp):
type
GType* = csize
else:
type
GType* = gulongHmmm...
The csize type (in Nim) is defined to be a regular (signed) integer, whereas in glib, GType is either a gsize (an unsigned int), or an unsigned long.
I also think that you're right that there could be problems in wrapping gtk_list_store_new since it is variadic; the way that the varargs pragma works, I think that this would be expecting multiple parameters of type gint, rather than gint + GType.
Err: Derp. Unsigned int should be the same size as a signed int (right?), so that shouldn't matter.
This is definitely a bug, and an old one, too. I ran into it a few months ago trying to compile Aporia on OS X, even mentioned it on IRC, but for some reason failed to file an issue on GitHub.
The underlying problem, as I recall, is that Nim's codegen relies on C prototypes for the stack layout rather than doing casts at each callsite. That works fine, except for C varargs functions (Nim varargs use a different stack layout that's not susceptible to this error), where the layout cannot be inferred from the ... part. On 64-bit architectures, that gets the stack layout wrong.
From the IRC logs today:
Araq kokozedman: I still haven't fixed a codegen bug that causes this.
So I guess it makes not much sense to update to latest git devel to avoid this bug.