RFC: KDE and namespace cleanness
Lubos Lunak
l.lunak at suse.cz
Fri Feb 14 10:22:38 GMT 2003
Hello,
I've threatened a long time ago
(http://lists.kde.org/?l=kde-core-devel&m=101925595027394&w=2) to write a
tool for checking namespace cleanness of KDE libraries, and I eventually got
to doing that. The thread also explains what would be the benefits of being
namespace clean - in short:
- we could use RTLD_GLOBAL for dlopen(), thus making dynamic_cast and
exceptions work across dlopen boundaries
- we wouldn't get strange crashes in case somebody introduces some simple
symbol e.g. in libkdecore that will be also used in some application (IIRC
Waldo hunted once such problem in KAccel which used class Entry).
- prelink currently doesn't work with dlopen, and AFAIK it's because of
conflicts, if we want to have at least a chance of prelink ever working with
dlopen, we'll need namespace cleanness (=no conflicts)
See the attached patch for admin/ (still work in progress, but it works
already). Every library may have another flag in Makefile.am listing allowed
public symbols, for example libkdecore_la_NMCHECK = K* NETWinInfo::* malloc
free . Those with trailing * are prefixes, the rest must match "exactly".
Arguments are ignored, because I don't consider them actually important (why
to allow one overloaded version and not another).
Would it be acceptable to specify the namespace restrictions this way? I
think the only way to make also 3rd party apps to become namespace clean is
to say "if you won't and you'll get crashes, don't blame us, you've been
warned". We cannot really use this in whole KDE until KDE4, but if this gets
in CVS, I'll for example require namespace clean modules for KWin (since the
interface will be new in KDE3.2), and IMHO all new interfaces should require
it.
I still have few issues with the checking, as can be seen from the comments
in the script. I'm not sure how much portable this stuff is, and also getting
a list of all symbols that are in every .so file isn't that easy (I tried to
do that in configure, but I don't know how to portably build a test app in
it). As those default symbols seem to all start with an underscore as
internal symbols, maybe just ignoring _* could do, but on the other hand,
this would allow any such symbol introduced in the libraries to slip in
unnoticed. Also, the script cannot check out-of-line copies of templates and
inline functions, as those are also generated for stuff included from other
libraries (i.e. all our libs have many copies of instantiations of Qt's
template classes). I don't know if it's possible to check this in a reliable
way.
One more problem is with things like BarIconSet(QString,KInstance*) or
i18n(QString). Those pollute the global namespace, even though the BarIcon
case is quite questionable, as the KInstance* argument makes it KDE specific.
Still, I think such "public" symbols should be eventually put in a namespace
and only make public for complication, like this:
namespace KDE
{
QPixmap BarIconSet(QString,KInstance*);
QString i18n(QString);
}
using namespace KDE;
BTW, one more related thing. I suggest committing the attached patch
kinit.cpp.patch . I think the comment in the patch explains it - we shouldn't
use main() as the entry point for kdeinit modules. This would also mean all
kdeinit enabled apps would have to use kdemain() as their entry point, and
all dummy.cpp files for kdeinit modules would eventually have to become real
.cpp files in cvs containing:
extern "C"
int kdemain( int argc, char* argv[]);
int main( int argc, char* argv[] )
{
return kdemain( argc, argv );
}
Comments?
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: admin.patch
Type: text/x-diff
Size: 5513 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030214/ed45d40b/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kinit.cpp.patch
Type: text/x-diff
Size: 1667 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030214/ed45d40b/attachment-0001.patch>
More information about the kde-core-devel
mailing list