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

[Daniel Veillard <veillard redhat com>]

On Thu, Mar 18, 2004 at 06:38:08PM +0100, Bjorn Reese wrote:
> Let me elaborate, using strlen as example:
>
> The Solaris libc implementation of strlen is highly optimized. When
> strlen searches for the terminating zero, it does not read the bytes
> individually, but rather loads an entire word (32 bits) into a register.
> This lowers the amount of traffic on the data bus; instead of four
> loads it only needs one. If the string, including the terminating zero,
> is 9 bytes long, then the third word loaded contains 3 uninitialised
> bytes. This is the action that Purify complains about. However, the
> strlen code will detect a zero byte regardless of the content of the
> other 3 bytes (don't ask me about the details, my SPARC is too rusty
> to decipher the strlen fu.)
>
> I have not investigated memcmp(), but I suspect that similar word
> loading trickery is used there.

  it's compiler specific, gcc on Linux with optimization turned on 
inline it to "repeat compare as byte" I think. It would hit the same
problem as Solaris if it were to use "repeat compare as word".
  I seems to me the Solaris libc approach is only okay because all
memory accesses on RISC is anyway done in chunk of at least 32bits
but they will be testing some uninitialized data even if the result
of the function is garanteed to be the same.
  Now the only question is whether replacing memcmp by strncmp
would really generate a difference. The best is to take one huge
xml instance and try testSAX for both on it. 

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/