Hi Patrick,
On Oct 4, 2009, at 12:25 , Patrick Ohly wrote:
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++.
It's the other way around - only with extern "C" I have a guarantee
the (many different, and partly exotic/obscure) compilers are forced
to use plain C calling convention. So from a multi-platform developer
point of view I'd like to keep this or a comparable enforcement in
place. No problem with #ifdeffing it out for one particular platform
(Linux) if it works better without.
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.
The problem is that these routines ARE public ones - usually not
directly called but assigned to pointers (I guess that's the "some
callbacks are set to functions in other source files" part you
mentioned) that are passed to the outside, i.e. DB plugins to call.
Adding SySync_ as prefix to those would keep the global namespace
clean.
As the name is irrelevant for the way these are used (as pointers
passed in the callback record), no problem with prefixing them. These
are conceptually entry points, so we could prefix them like the other
entry points already are.
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.
Yes. I hope any problems arising from having two copies of
libsynthesis linked will become history now :-)
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
