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

["Eric S. Eberhard" <flash vicspdi com>]

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  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml

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

http://www.vicspdi.com

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

http://www.vicspdi.com/ourpics/index.html