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. 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<DTDElementDecl *>
(elemDecl);
if (dtdelemDecl != NULL) {
attDef = dtdelemDecl->getAttDef(namePtr);
} else {
SchemaElementDecl* schelemDecl =
dynamic_cast<SchemaElementDecl *> (elemDecl);
if (schelemDecl != NULL) {
attDef = schelemDecl->getAttDef(suffPtr, uriId);
}
}
}
}
//-----------------------------------------------------------------
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.
On 21 Sep 2009, at 11:52, Ben Griffin wrote:
Essentially the value of fAttDefs is 0x0 but it isn't?!
The method here is causing difficulties for me.
When fAttDefs is NULL, it's value is appearing as
0xfffffffe00000001, so it resolves to true and therefore the getter
(for a NULL object) is invoked, causing an inevitable crash.
I am not sure why the value of fAttDefs appears as 0x0 on the right
side of my screen and as 0xfffffffe00000001 on the bottom.
Maybe I am not setting a compile flag correctly?
Is this something to do with 64 bit addressing? (This is XCode on
Snow Leopard)