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

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 Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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