You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by chris schaefer <ch...@seacoms.com> on 2000/12/14 02:33:13 UTC
probably a bug in createNodeIterator
Hi All:
First off, thank Khaled for you reply! got me looking into the right
places!!!!
I've finally cut away all of the unimportant parts of my code and I'm left with
what I believe to be heart of the problem. I'm still not clear what is causing
the problem though I think I understand the symptoms well.
It appears as though if I pass in an empty element ( for example
<HostInZone/> ) or a normal element pair with no white space ( for example
<HostInZone></HostInZone> ) to the createNodeIterator as the "root" parameter
then the createNodeIterator will proceed to use REST of the document as the area in
which to search for stuff which is accepted by the filter.
My belief is that this is incorrect behavior. What I would expect is that if the
root node is "empty" ( meaning has no children: elements or ignorable white space )
then the iterator would return a NULL node the first time nextNode is called.
I'd love to be able to dig into the xerces code and and figure out what the exact
bug is on this one, and I'll probably attempt to figure it out myself in the spirit
of OSS. However, since my expectation is that it's buried deep within code I've
never seen, I'll send along my XML and my modified DOMPrint code, and hope that
someone else can also look into this.
The XML demonstrates several different way the failure can manifest itself, I would
recommend simplfying things a bit if you want to actually debug. If the bug gets
fixed, this XML should deliver ONLY the nodes which have roles equal to something
that I want.
-C-
Re: probably a bug in createNodeIterator
Posted by chris schaefer <ch...@seacoms.com>.
Ah you are right!
I got so excited that I'd found a bug, that I forgot that I was running an older revision, and that someone else had probably already
fixed it. The new revision fixes all my reproduction cases.
-C-
Gareth Reakes wrote:
> Hello,
> I believe that bug has been fixed. Try downloading the nightly
> build.
>
> Gareth
>
> On Wed, 13 Dec 2000, chris schaefer wrote:
>
> > I now believe there is a bug in the tree walking code contained here:
> >
> > NodeIteratorImpl::nextNode (DOM_Node node, bool visitChildren)
> > lines 327 forward
> > in NodeIteratorImpl.cpp
> >
> > Apparently if root node passed into the createIterator then we get the following sequence:
> > 1) first time through this function returns fRoot - correctly
> > 2) second time through this function returns the next sibling of the parent of fRoot, instead of NULL which is what it should do.
> >
> >
> > -C-
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: probably a bug in createNodeIterator
Posted by Gareth Reakes <ga...@decisionsoft.com>.
Hello,
I believe that bug has been fixed. Try downloading the nightly
build.
Gareth
On Wed, 13 Dec 2000, chris schaefer wrote:
> I now believe there is a bug in the tree walking code contained here:
>
> NodeIteratorImpl::nextNode (DOM_Node node, bool visitChildren)
> lines 327 forward
> in NodeIteratorImpl.cpp
>
> Apparently if root node passed into the createIterator then we get the following sequence:
> 1) first time through this function returns fRoot - correctly
> 2) second time through this function returns the next sibling of the parent of fRoot, instead of NULL which is what it should do.
>
>
> -C-
>
Re: probably a bug in createNodeIterator
Posted by chris schaefer <ch...@seacoms.com>.
I now believe there is a bug in the tree walking code contained here:
NodeIteratorImpl::nextNode (DOM_Node node, bool visitChildren)
lines 327 forward
in NodeIteratorImpl.cpp
Apparently if root node passed into the createIterator then we get the following sequence:
1) first time through this function returns fRoot - correctly
2) second time through this function returns the next sibling of the parent of fRoot, instead of NULL which is what it should do.
-C-