Return-Path: Delivered-To: apmail-xerces-c-users-archive@www.apache.org Received: (qmail 11060 invoked from network); 21 Sep 2009 20:48:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 21 Sep 2009 20:48:40 -0000 Received: (qmail 98079 invoked by uid 500); 21 Sep 2009 20:48:40 -0000 Delivered-To: apmail-xerces-c-users-archive@xerces.apache.org Received: (qmail 98031 invoked by uid 500); 21 Sep 2009 20:48:40 -0000 Mailing-List: contact c-users-help@xerces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: c-users@xerces.apache.org Delivered-To: mailing list c-users@xerces.apache.org Received: (qmail 98021 invoked by uid 99); 21 Sep 2009 20:48:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Sep 2009 20:48:40 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 21 Sep 2009 20:48:38 +0000 Received: (qmail 11027 invoked from network); 21 Sep 2009 20:48:18 -0000 Received: from localhost (HELO ?IPv6:::1?) (127.0.0.1) by localhost with SMTP; 21 Sep 2009 20:48:18 -0000 Message-ID: <4AB7E680.2050508@apache.org> Date: Mon, 21 Sep 2009 13:48:00 -0700 From: David Bertoni User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: c-users@xerces.apache.org Subject: Re: BUG found in IGXMLScanner2.cpp References: <609365C6-EC59-4A8E-93EF-8F38330DC96F@redsnapper.net> <912605ED-E77D-4AB9-BDF6-966AE2FAA2C6@redsnapper.net> In-Reply-To: <912605ED-E77D-4AB9-BDF6-966AE2FAA2C6@redsnapper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Ben Griffin wrote: > I posted an earlier message up on 'c-users'; the problem there was to do > with a bad cast, so I have cross-posted to c-dev. > > There are cases where (and I really don't know how) a document is > considered to be governed by a DTD when it's actually governed by a > Schema; and sometimes the element declaration is recognised as being a > SchemaElementDecl rather than a DTDElementDecl. IE, it is not true that > if fGrammarType == Grammar::DTDGrammarType then the XMLAttDef* attDef is > necessarily a DTDElementDecl. I think what you mean is that an XMLElementDecl is always a DTDElementDecl, if the fGrammarType is Grammar::DTDGrammarType. We should figure out why this is happening, as that's the underlying bug. > Because of this, there's a crash occuring after the forced cast at: > > //----------------------------------------------------------------- > // Find this attribute within the parent element. We pass both > // the uriID/name and the raw QName buffer, since we don't know > // how the derived validator and its elements store attributes. > else { > if(fGrammarType == Grammar::DTDGrammarType) { > attDef = ((DTDElementDecl *)elemDecl)->getAttDef ( namePtr); > } > } > //----------------------------------------------------------------- > > > The following code (using dynamic casts) works fine (doesn't crash) - > the second cast (to SchemaElementDecl) IS being used in some cases. > //----------------------------------------------------------------- > // Find this attribute within the parent element. We pass both > // the uriID/name and the raw QName buffer, since we don't know > // how the derived validator and its elements store attributes. > else { > if(fGrammarType == Grammar::DTDGrammarType) { > DTDElementDecl* dtdelemDecl = dynamic_cast > (elemDecl); > if (dtdelemDecl != NULL) { > attDef = dtdelemDecl->getAttDef(namePtr); > } else { > SchemaElementDecl* schelemDecl = > dynamic_cast (elemDecl); > if (schelemDecl != NULL) { > attDef = schelemDecl->getAttDef(suffPtr, uriId); > } > } > } > } > //----------------------------------------------------------------- Xerces-C doesn't use dynamic cast as a matter of policy, so we'll need to figure out why the grammar type is wrong. This could cause problems in other parts of the code as well. > > Alternatively, if the attDef Must be a DTDElementDecl when fGrammarType > == Grammar::DTDGrammarType, then an error should be thrown.... > I will try to find a minimal use case, rather than the current set which > involves 24 grammars and several nested namespaces in the file being > parsed. That would be great, thanks! Dave