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