Re: Unfortunately, not yet solved (Was: Re: Problem solved! (Was: Re: [xml] valgrind errrors with this small sample program)) Comment on code for multi-O/S

I find all this multi-O/S coding a real pain and I am really impressed by how well libxml2 handles it.

I program mostly on AIX. On AIX all those string/memory command such as memcmp, strcmp, strcpy, etc. all work perfectly even if you pass NULL for the string arguments ( and intuitively in that NULL is considered smaller than any other string, two NULLS are equal, etc).

Much to my surprise when I ported to Linux I entered the world of massive core dumps! Which I had to deal with. My recent port to NT has been even more fun. I have done 3-4 others as well. And libxml2 makes it look sooo easy :-)

I even stole some programming techniques (many moons ago) from libxml (the precursor) ...

At 10:38 AM 3/18/04, Bjorn Reese wrote:
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.

xml mailing list, project page
xml gnome org

Eric S. Eberhard
(928) 567-3727          Voice
(928) 567-6122          Fax
(800) 569-1122 Denver Office (I am never there, you can leave a message)
(720) 339-4765          Cell

Completely updated web site of personal pictures with many new pictures! Includes horses, dogs, Corvairs, and more.

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