Re: Unfortunately, not yet solved (Was: Re: Problem solved! (Was: Re: [xml] valgrind errrors with this small sample program))

Holger Rauch said:
Hi William, hi Daniel!

First of all, thanks to both of you for the quick responses and the
detailed anaylisis of the Purify output!


Ok, William, you were right, indeed using "strncmp" instead of
fixed the error reported by Purify (I left the order of arguments
as it was originally).

What I'm wondering about is this:

1. Either this error is also present when compiling libxml2 on Linux
   valgrind fails to detect it as such (in this concrete case) or

2. "memcmp" works as expected on Linux and thus valgrind does not
report the
   error (in such a case valgrind would be right, of course :-))

Can either one of you (or somebody else) enlighten me on this issue?

Well, before I composed my last response I spent around 3 hours
trying everything I could think of to make a similar program fail on
the x86 - my intention was to present Daniel with a simple test
which failed on that architecture and let him make the difficult
decisions :-).  Unfortunate(?)ly, I couldn't make it happen.  I'm
still not ready to just forget about it - my next step is to try to
trace it down to the assembler level to discover how the gcc / libc
writers have gotten away with it!  I'm fairly certain that valgrind
is reporting reliably, and it's the compiler/library that somehow
succeeds in preventing the problem.  If I ever do figure it out,
I'll certainly report it to this thread.

I guess that we could change the libxml2
code, but the reason memcmp is used is to improve the timing (and
it's executed very frequently).

I admit I don't have enough experience to really judge it, but is
really such a great difference in performance if "strncmp" instead
"memcmp" is used? Has libxml2 code been profiled with regard to this

Another alternative would be to put
the choice between memcmp and strncmp within an #ifdef to identify
library/processor/runtime or whatever.

Probably best if "strncmp" does really have a great impact on

Thanks again!

Kind regards,


I think it's worthwhile to consider the problem for a bit, and see
if other list members have any relevant comments / suggestions.  I'm
particulary hoping that Bjorn Reese may have some insights, as I
consider him one of the most knowlegeable list members in this area.
 I would expect some decision will be made before the next release.

Glad it's now working for you.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]