We’ve just changed the type of the separators argument in GLib.strsplit_set() from a string to a byte array in GLib main, which better matches its semantics. In C, this doesn’t actually change ABI, but for introspected bindings it does.
Bindings will probably want to add an override to:
handle backwards compatibility for apps which pass a string
transparently add the necessary zero-terminator element so apps don’t have to add that themselves when passing an array of bytes (edit: as Sergey points out, this will probably happen automatically anyway due to the zero-terminated=”1” annotation)
Sorry in advance for the side question and comment, but…
ABI or API? It seems odd to me talk about the ABI for introspection bindings. In this case it seems that the API is affected as well.
By default if both are affected I personally choose the term API because that’s what matters most and that’s what most people understand already. If only the ABI is affected there is only the need to recompile [1], after all, and it’s a more esoteric thing. The ABI is usually not what the user-developer consumes.
I know that the terms API/ABI are often used interchangeably, but it seems that using the term ABI by default seems wrong to me, in common situations.
[1] I’m not even sure that this is always true, but for the sake of the argument, let’s simplify
I wouldn’t read too much into my choice of ‘ABI’ vs ‘API’. The main thing is that the annotations for this function have changed, which will have changed the typelib and the introspection XML.
