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 Grace Yan <gy...@cisco.com> on 2000/07/18 00:21:43 UTC

FW: Xerces bug?

My co-worker might have found a bug in Xercer, and he ask me to report
it for him. I am posting what he said here, 
to get a first pass to see if anyone else have encounter the problem and
to check if it is really a bug or misunderstanding.

--snip

> In the DOM code there is an iterator, DOM_NodeIterator() which calls
> DOM_NodeIterator(DOM_NodeIteratorImpl) that takes whatToShow as one of
> its four parameters.  whatToShow allows the user to specify which type
> nodes should be shown when iterating over a collection of nodes (I
> wanted to show only element nodes).  whatToShow eventually finds its
> way to NodeIteratorImpl::acceptNode as fWhatToShow and is processed
> along with the node type in the following expression:  return
> ((fWhatToShow & ((1 << node.getNodeType()) - 1)) != 0).  Since the
> value of DOM_NodeFilter::SHOW_ELEMENT is enumed to 0x00000001, it
> appears that for SHOW_ELEMENT the expression will always be true for
> all types.  
> 
--snip --

thanks
grace

Re: Xerces bug?

Posted by Joe Polastre <jp...@apache.org>.
Grace,

  I think you're misinterpreting the code, here is how it works.

  The flags are enumed to a bitmask.  All of the flags are stored in 1 short
variable (to save space) by their enum bitmask.

  When a value is needed, the bitmask is "and"ed with the short variable.
The result is a zero (false) or one (true) depending on how that bit was set
by the setter functions.

  so for example, the SHOW_ELEMENT bit is the 1st bit in the short.
fWhatToShow is the short.  ((1 << node.getNodeType()) - 1) returns a bit
mask shifted the correct number of positions.

  get it?  I assure you that it is really NOT an elaborate way of saying:

  return SHOW_ELEMENT;

  It _is_ possible, however, that there is a bug in the setting of this
flag.  If that is the case, it is probably somewhere else in the code.

-Joe Polastre  (jpolast@apache.org)
IBM Cupertino, XML Technology Group


----- Original Message -----
From: "Grace Yan" <gy...@cisco.com>
To: <xe...@xml.apache.org>
Sent: Monday, July 17, 2000 3:21 PM
Subject: FW: Xerces bug?


>
> My co-worker might have found a bug in Xercer, and he ask me to report
> it for him. I am posting what he said here,
> to get a first pass to see if anyone else have encounter the problem and
> to check if it is really a bug or misunderstanding.
>
> --snip
>
> > In the DOM code there is an iterator, DOM_NodeIterator() which calls
> > DOM_NodeIterator(DOM_NodeIteratorImpl) that takes whatToShow as one of
> > its four parameters.  whatToShow allows the user to specify which type
> > nodes should be shown when iterating over a collection of nodes (I
> > wanted to show only element nodes).  whatToShow eventually finds its
> > way to NodeIteratorImpl::acceptNode as fWhatToShow and is processed
> > along with the node type in the following expression:  return
> > ((fWhatToShow & ((1 << node.getNodeType()) - 1)) != 0).  Since the
> > value of DOM_NodeFilter::SHOW_ELEMENT is enumed to 0x00000001, it
> > appears that for SHOW_ELEMENT the expression will always be true for
> > all types.
> >
> --snip --
>
> thanks
> grace
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>