Bug#227538: kdelibs: mixed results on 3.2.2
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
Reply to: