On Sat, 2009-10-03 at 14:33 +0100, Lukas Zeller wrote:
> But I have a questions about the following commits:
>
> e90286c1a9 (API DB Plugin Agent: removed extern "C"),
> c698d5cf95 (syncappbase: turned extern "C" into static functions)
> and
> c31d3e14c0 (syncappbase: removed extern "C")
>
> These routines are declared extern C to make sure they have C calling
> convention.
That's what I was asking about in my mail before I made these changes:
are you aware of platforms where 'extern "C"' changes the calling
convention? That's not the case on Linux and 'static extern "C"' is not
accepted by g++.
If 'extern "C"' had the "side effect" of changing the calling convention
in addition to the name mangling, then 'static extern "C"' should be
allowed.
> It is not true that these are used only within the engine
> - pointers to them are directly put into the callback structure that
> is passed out to the database plugins to call, so they are part of the
> ABI.
I know. I just wondered whether this is really necessary. Because I
needed a solution on Linux, I went ahead with this as the most
convenient solution, knowing that more discussion would be needed before
it could be merged.
> I'm not saying this is a nice solution, but its safe for all platforms
> and compilers.
>
> More elegant ways to do the same are welcome :-)
extern "C" {
static ...
}
is one such solution: it ensures C calling convention (if necessary) but
hides the symbols. But it doesn't work in all cases, because some
callbacks are set to functions in other source files.
Adding SySync_ as prefix to those would keep the global namespace clean.
This isn't such a big problem, though, because with unilib there are no
name clashes inside the lib and these additional symbols can be hidden
inside a .so or .DLL.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
