Remove length argument from SelectionData::set_text

[Susurrus]

The len argument should be inferred from the str argument

[GuillaumeGomez]

Agreed. However, I'm not sure how we could automate this easily. Just checking if a const char* is followed by an integer variable maybe?

[Susurrus]

I think if a pointer of some type was followed by some integer type that was named len, length, or *_length, that would probably cover it. At least the following functions could be fixed by this check (note I didn't do an exhaustive search):

• gtk_css_provider_load_from_data()
• gtk_editable_insert_text()
• gtk_selection_data_get_text()
• gtk_selection_data_set()
• gtk_text_buffer_insert_with_tags()
• gtk_text_buffer_insert_with_tags_by_name()
• gtk_tree_model_rows_reordered_with_length()
• gtk_tree_path_new_from_indicesv()

I'm wondering if this information can be automatically parsed from the docs in a more remote way. If you look at the HTML GTK docs for things you see they annotate pointers that are arrays with an [array length=VARIABLE_NAME] annotation. If we could get that in machine-readable form, like in the gir-files, this would all be trivial. Maybe this is something to bring up during the GTK conference next week?

[EPashkin]

gtk_css_provider_load_from_data already says array length="1" gtk_editable_insert_text is just string that not ends with \0 gtk_selection_data_set_text (not get) is same gtk_selection_data_set says array length="3" I think that it be good if it annotated in .gir (but with another attribute) Until then we can do autodetect but need way do disable replacing concrete function in config.

[EPashkin]

Before I thought that it will done by manual adding to concrete function after https://github.com/gtk-rs/gir/issues/264 but maybe I will be good in automatic way

[EPashkin]

Related issue for automatization https://github.com/gtk-rs/gir/issues/376

[GuillaumeGomez]

It'll require to check all these functions really carefully but it's a big improvement if we're able to do it! :)

[sdroege]

I think most of the ones here are not covered because of either 1) unsupported CArray type (fundamental types e.g. are not supported, only pointers). Next on my list 2) missing array-length annotation in GTK (gtk_selection_data_set_text for example, someone please check all of them and file bugs)

[sdroege]

https://bugzilla.gnome.org/show_bug.cgi?id=784022 IMHO we should just patch the GTK .gir file once that is merged.

For fundamental types in arrays, see https://github.com/gtk-rs/gir/issues/388

[EPashkin]

Also don't see this as bug, as it not array and length can be -1

[sdroege]

It is unsafe because you could now provide a length that is bigger than the actual length of the string

[EPashkin]

Normally we replace these functions with manual .len() and thus remove unsafety. If you do something like array_len config we can use it to generate same way

[sdroege]

It's generally unsafe the way how it is in Pango and others right now as especially runtime generated bindings will also expose the length and have no easy way of "configuration" to override this. It's really something that has to be fixed at the gobject-introspection / C library level.

Also these are all actually arrays. "Strings" are arrays in C, and here everywhere defined as [u8] with the additional constraint that they are valid UTF8 (basically just how String in Rust is Vec with the same constraint). And the lengths given here are all in bytes, not characters, so consistent with the [u8] (aka char *) definition.

[sdroege]

See https://github.com/gtk-rs/gir/pull/387#issuecomment-310350093 . Needs manual bindings for these functions that take a string+length, or return a string+length