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

["William M. Brack" <wbrack mmm com hk>]

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!

  <snip>
> Ok, William, you were right, indeed using "strncmp" instead of
> "memcmp"
> 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
> and
>    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
> there
> really such a great difference in performance if "strncmp" instead
> of
> "memcmp" is used? Has libxml2 code been profiled with regard to this
> issue?
>
> > 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
> performance.
>
> Thanks again!
>
> Kind regards,
>
>       Holger

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.

Bill