Hello Phil, Thanks for your taking some of your time to answer. Mean while, I've had quite a long chat about all this (special thanks to ptomato[m] and ebassy), and a pointer to how GJS has implemented preparation and calls to g_function_info_invoke, beautifully written, but 'forced to' a level of complexity that could be avoided, imo.
Thanks for the links as well.
> ...
> argc [inout][optional]
> argv [inout][array length=argc][optional]
Yes, that is what I was expecting (talking about argc), together with an
accurate
description: argc is a pointer to an integer, which can be NULL, it is not an
integer.
> The annotations for [clutter_init][5] are not quite as you have quoted:
> they do include the array annotation on argv:
Sorry, I I did copy from somewhere it didn't mention that, but argv was and
still is not 'the problem' I wanted to talk about, so let's forget about it.
> argc [inout]
> argv [array length=argc][inout][allow-none]
> It could be argued that the array annotation (that links argc to argv)
> ...
The above version is the one I expect
argc [inout][optional]
argv [inout][array length=argc][optional]
together with an accurate description (for argc)
a pointer to the number of arguments in argv
[ which I prefer to "... of command line arguments", but ok
> The extra level of indirection for out and inout arguments is not
> counted by [g_type_info_is_pointer][6]. (Therefore 'direction' needs to
> be known to determine the C type from the GIArgInfo data.)
I haven't been convinced, imo, the GIArgInfo, for argc, should always tell us
exactly what the C function argument is, in this case, in substance:
...
type-tag = pointer
pointing-to = one-integer
...
is-pointer? = #t
may-be-null? = #t
...
gi-argument-field = v-pointer
Regards,
David
pgpdCMZJTpcgK.pgp
Description: OpenPGP digital signature
_______________________________________________ language-bindings mailing list [email protected] https://mail.gnome.org/mailman/listinfo/language-bindings
