Page 1 of 1

ABI Compatibility of identifiers that are not exposed

Posted: Mon Jul 20, 2015 12:24
by YaronCT
Hi,

Is it allowed to change, for example, the prototype of a method in "OpenGL3ShaderManager", which is not defined with "OPENGL_GUIRENDERER_API" or something similar that indicates that it should be exposed? That is, if I want to maintain ABI compatibility.

Re: ABI Compatibility of identifiers that are not exposed

Posted: Sat Jul 25, 2015 12:32
by Ident
According to : https://techbase.kde.org/Policies/Binar ... s_With_C++
This is legal, because it fits the following description: "export a class that was not previously exported." listed under "DO's"

Feel free to expose any classes that should be exposed and were not!

Re: ABI Compatibility of identifiers that are not exposed

Posted: Sat Jul 25, 2015 12:41
by YaronCT
Ok, but my question was not whether it's legal to expose the class, but whether it's legal to change the prototype of a method of the class (leaving the class unexposed). So, If try to read between your words, it's legal. I was just wondering because in MSVC u must use __declspec(dllexport) do expose a symbol, but e.g. in GCC I think every symbol is automatically exposed, unless it's defined explicitly to have static linkage, or declared/defined with something like "__attribute__ ((visibility ("hidden")))" (which we do not seem to use in CEGUI code. Perhaps we should?). So perhaps e.g. with GCC some1 would still use a method of the class even though it's not explicitly "exposed", and therefore changing its prototype would break ABI compatibility.

Re: ABI Compatibility of identifiers that are not exposed

Posted: Sat Jul 25, 2015 12:43
by Ident
Sorry, clearly I misunderstood your question. By "prototype" do you mean "superclass"? I am not sure what "prototype" means in this context.


Edit: Okay I just looked it up and I guess you mean "function prototype". Let me re-read.

Re: ABI Compatibility of identifiers that are not exposed

Posted: Sat Jul 25, 2015 12:48
by YaronCT
No, by changing the prototype of a method of a class, I mean e.g. change its parameters. So, say, in the definition of the class "OpenGL3ShaderManager", change:

Code: Select all

void initialiseShaders();

to:

Code: Select all

void initialiseShaders(bool foo);

And then, if a GCC user used the old prototype, ABI compatibility would be broken. (And he can do that, despite the fact that the class isn't defined with "OPENGL_GUIRENDERER_API".)

Re: ABI Compatibility of identifiers that are not exposed

Posted: Sat Jul 25, 2015 12:55
by Ident
Thats a good question. First of all the obvious thing: If the method initialiseShaders is private or protected and non-static it doesnt matter, it can be removed, changed, whatever. If it is public however, then I believe it can't be removed for the reason you gave, also we typically go by this:
https://techbase.kde.org/Policies/Binar ... s_With_C++

Which states that existing functions of any type cant be removed. What we would typically do is to retain the old function ,mark it as deprecated and call the newly added initialiseShaders(bool foo) from the old function to not have any boilerplate code left. I would like to hear Martin's input on this though as well, just to be sure.

Re: ABI Compatibility of identifiers that are not exposed

Posted: Sat Jul 25, 2015 13:03
by YaronCT
Are u sure about "protected"? A used might have inherited the class and used the protected method from there! I think it applies only to private members.

Re: ABI Compatibility of identifiers that are not exposed

Posted: Sat Jul 25, 2015 13:06
by Ident
True, it actually only says "private" in the link and your reasoning completely makes sense. I am really not an expert on ABI compatibility as you may have noticed ;)

Re: ABI Compatibility of identifiers that are not exposed

Posted: Mon Jul 27, 2015 08:35
by Kulik
We only maintain ABI compat for visible symbols, so yes, this is perfectly legal.

Re: ABI Compatibility of identifiers that are not exposed

Posted: Tue Jul 28, 2015 08:47
by YaronCT
Kulik,

but in GCC, symbols **are** visible by default, unless the "-fvisibility=hidden" compilation flag or "#pragma GCC visibility push(hidden)" is put in the code. That means, users might already use some symbols that we didn't intend to make visible. Don't u think we should use one of these options to prevent the visibility of the symbols we don't want visible?

Re: ABI Compatibility of identifiers that are not exposed

Posted: Tue Jul 28, 2015 08:50
by YaronCT