GNOME Bugzilla – Bug 793273
Missing array length introspection annotation for vte_terminal_feed_child
Last modified: 2018-03-03 12:29:50 UTC
vte_terminal_feed_child does not have an array length introspection annotation, unlike vte_terminal_feed_child_binary. Therefore bindings to vte_terminal_feed_child in other languages will need to specify the length or -1 if it is known that the language bindings supply a zero-terminated string to the C function. I can't think of a benefit to language bindings - is no length annotation intentional?
Not intentional, no. (However this function is rarely needed; what are you using it for?)
I have a mini text editor with a VTE widget built-in that runs a REPL (of a Standard ML compiler, FWIW). As well as using vte_terminal_paste_primary to evaluate selected text in the REPL, I use vte_terminal_feed_child to send the string ";\n" to the REPL, which is useful to force top-level declarations to be evaluated.
Created attachment 368105 [details] [review] Fix annotation for vte_terminal_feed_child Patch in case it's useful.
Comment on attachment 368105 [details] [review] Fix annotation for vte_terminal_feed_child (element-type gchar) Why change that from utf-8 (which is what's required by this function) ?
We would have (element-type utf8) if the elements of the container type (in this case, array) were strings. For this function, text is just a string which is an array of chars. I suspect the (element-type utf8) annotation was being ignored before because there was no container type or (array ...) annotation.
In fact, the patch causes the following GISCAN warning to disappear: src/vtegtk.cc:2630: Warning: Vte: Unknown container Type(target_fundamental=utf8, ctype=char*) for element-type annotation (I am testing the patch on top of 0.51.1)