ABI Compatibility of identifiers that are not exposed

[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.

[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!

[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.

[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.

[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".)

[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.

[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.

[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

[Kulik]

We only maintain ABI compat for visible symbols, so yes, this is perfectly legal.

[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?

[YaronCT]

(See https://gcc.gnu.org/wiki/Visibility)