You are viewing a plain text version of this content. The canonical link for it is here.
Posted to p-dev@xerces.apache.org by "Jason E. Stewart" <ja...@openinformatics.com> on 2002/11/12 23:34:23 UTC

["Tinny Ng" ] Re: Bizarre C++ error with Xerces-2.x

Jason,

> you. Is there anything dangerous about how this code is casting things
> as void* and then to DOMNode* that could cause vtable trouble, and
> make the compiler wander off into the wrong method?

Yes it seems to be.   Since DOMDocument is inherited from 3 classes 1.
DOMDocumentRange 2. DOMDocumentTraversal and 3. DOMNode; while the others,
e.g. DOMElement, is only inherited from DOMNode.   Two extra parent classes
for DOMDocument may cause a problem when casting to void*.

I can reproduce your problem in C++

        DOMDocument* doc = impl->createDocument(
                    0,                    // root element namespace URI.
                    X("company"),         // root element name
                    0);                   // document type object (DTD).

        DOMElement* rootElem = doc->getDocumentElement();

        DOMNode* n1 = (DOMNode*) doc;                      // ok
        n1->getFirstChild();

        DOMNode* n2 = (DOMNode*) rootElem;                      // ok
        n2->getFirstChild();

        DOMNode* n3 = (DOMNode*) (void*) doc;        // <======== this one
has problem
        n3->getFirstChild();

        DOMNode* n4 = (DOMNode*) (void*) rootElem;                      //
ok
        n4->getFirstChild();

So is it you must cast to void* first?   Can you cast to DOMNode* directly
like n1 above?

Tinny

----- Original Message -----
From: "Jason E. Stewart" <ja...@openinformatics.com>
To: "Gareth Reakes" <ga...@decisionsoft.com>; "Tinny Ng"
<tn...@ca.ibm.com>
Sent: Tuesday, November 12, 2002 3:21 PM
Subject: Bizarre C++ error with Xerces-2.x


> Hey Gareth and Tinny,
>
> I'm the maintainer of the Xerces-Perl code-base, which is built as a
> thin glue-code layer atop Xerces-C. Because of a C++ problem that I've
> run into, Xerces-Perl is lagging far behind Xerces-C (I've not been
> able to make any 2.x releases) because of a bug that I cannot
> understand.
>
> I appologize for writing to you directly, but I'm stumped, and I'm
> hoping that if I get some advice from some much more experienced c++
> programmers (yourselves), perhaps we can solve this and I can release
> Xerces-P-2.1.0, and I would be *extremely* grateful.
>
> The problem exists with the new DOM code, and in only one particular
> instance so far (although I fear it's a more general problem). Also,
> I've tried compiling on both PowerPC and i386 linux as well as solaris
> using both gcc-2.95 and gcc-3.2, and the problem appears on all of
> them.
>
> What happens is in a a call to DOMNode::getFirstChild() of the Node is
> a DOMDocument soemthing very strange happens, but for all other node
> types the code behaves as expected. For DOMDocuments, instead of
> invoking getFirstChild() my code actually invokes createComment()!!
> And it returns a bogus comment node.
>
> Here is what the code looks like:
>
>         DOMNode *arg1 = (DOMNode *) 0 ;
>         DOMNode *result;
>         int argvi = 0;
>         dXSARGS;
>
>         if ((items < 1) || (items > 1)) {
>             SWIG_croak("Usage: DOMNode_getFirstChild(self);");
>         }
>         {
>             if (SWIG_ConvertPtr(ST(0), (void **) &arg1,
SWIGTYPE_p_DOMNode,0) < 0) {
>                 SWIG_croak("Type error in argument 1 of
DOMNode_getFirstChild. Expected _p_DOMNode");
>             }
>         }
>         {
>             try {
>                 result = (DOMNode *)((DOMNode const
*)arg1)->getFirstChild();
>
>             }
>
> the SWIG_ConvertPtr() method takes a Perl struct and digs out the
> internally stored C++ pointer to the DOMNode, storing it in arg1.
>
> I can give you more details than this, but I didn't want to overwhelm
> you. Is there anything dangerous about how this code is casting things
> as void* and then to DOMNode* that could cause vtable trouble, and
> make the compiler wander off into the wrong method?
>
> Thanks ahead of time for your help,
> jas.