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

[Holger Rauch <holger rauch heitec de>]

Hi William, hi Daniel!

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

On Thu, 18 Mar 2004, William M. Brack wrote:

> Daniel Veillard said:
> > [...]
> >   Can you try to change line 7567 of parser.c from
> >     if ((tlen > 0) && (memcmp(ctxt->input->cur, ctxt->name, tlen) ==
> > 0)) {
> > to
> >     if ((tlen > 0) && (memcmp(ctxt->name, ctxt->input->cur, tlen) ==
> > 0)) {
> >
> >  and see if this fixes Purify report ?

I did this and the error message still appeared in Purify. William seems
to be right (please see below).
 
> [...] 
> To "fix" the problem for the Solaris, I would assume changing the
> "memcmp" to be a "strncmp" will make it happy (unfortunately I have
> no way to test that - Holger, I'd appreciate it if you could try
> that and report back).

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?

> 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