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
Attachment:
pgp8pr7byzT6B.pgp
Description: OpenPGP digital signature