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

[Bjorn Reese <breese mail1 stofanet dk>]

On Thu, 2004-03-18 at 15:59, William M. Brack wrote:

> 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.

With an introduction like that, I have no option but to reply :)

I cannot remember if I have seen this behavior for memcmp, but I have
for write and strlen, and I expect the problem to be the same.

Purify is reporting a false positive. It is harmless and best solved by
letting Purify suppress UMRs from memcmp.

Furthermore, the observed behavior is Solaris-specific, so do not be
alarmed that valgrind does not detect any wrong-doings.

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.