Chris Cheney writes: > On Sat, Jun 26, 2004 at 04:20:12AM +0200, Dominique Devriese wrote: > -snip patch- >> > I haven't heard anything about this bug in a while. Does this >> > patch work? >> >> I'm pretty sure it fixes the problem, yes. >> >> > Has been applied to packages that have been released? >> >> It's committed in pkg-kde/kdelibs, but apparently it's still not in >> any uploaded kdelibs version. Chris must have missed this simple >> patch...
> Its not committed in the main tree afaict, where is it? Right, I didn't commit it yet, I misinterpreted an empty "svn up" output.. Guess I'm still too used to the old CVS way :) > I will add it to the next upload if it seems to help. I think > someone told me before what changing this patch does but it doesn't > seem to be in the bug log. Yeah, I seem to remember eplaining it to you once.. > The way it currently is seems to work for me, what bug do you see > with this exactly? > calc-amd64:~# kde-config --path config > /root/.kde/share/config/:/etc/kde3/ Well, the problem is that what's currently there happens to work in some cases, but doesn't work in other cases, like the one that the bug report was about. I'll try to explain it again: It's all about the string comparison: If somestring is a variable of type "char*", then 'somestring == "something"' in C++ and C is not a string comparison, but a pointer comparison. It checks that the variable somestring points to the same region of memory that "something" is put in. Now, the C++ standard leaves some behaviour wrt. string storage undefined, but what g++ does, is that if it finds two string literals containing the same thing, it stores them only once, if the two strings are in the same compile unit or link unit or whatever unit it takes for this. Anyway, what happens in your case ( where it works properly ) is that, the first time that the function is called with "something" as an argument, it is by chance one of the identical strings in the same compile unit, and the check happens to succeed. The function then caches the result it just calculated, and all further invocations of the function give the correct result. However, if the first invocation of the function happens to be a string from another compile unit, then the pointer comparison fails, the function calculates the wrong result, and this result is cached for all further invocations. I debugged the bug that was described in this bug report, and this is in fact the case. Anyway, I'll be committing the patch now, if you don't mind, with the above explanation in the commit log... cheers domi