this is great work! i am happy to help as much as i can, esp since you stepped thru it....
On Fri, 1 Mar 2002, Christian Kruse wrote: > Hi, > > On Thu, 28 Feb 2002 12:40:49 -0800 (PST) > John Utz <[EMAIL PROTECTED]> wrote: > > > OK, we see here that the 'this' pointer and the urlText string are NULL! i > > assume that the this is supposed to point to the XMLURL instance but i > > dont really know. > > I think the error is in parsers/SAXParser.cpp: > SAXParser::parse(const char *const systemId, const bool reuseGrammar): > > fScanner->scanDocument(systemId, reuseGrammar); > > This calls > > void XMLScanner::scanDocument( const XMLCh* const systemId > , const bool reuseGrammar) > > > you send const char *const systemId as a const XMLCh *const systemId. > XMLCh is, when I understand rightfully, a wchar_t. In XMLScanner::scanDocument > a XMLURL object is created with this const XMLCh* const, which is in deed > a const char *const. The XMLURL-Constructor > > XMLURL::XMLURL(const XMLCh* const urlText) > > is called, which calls > > void XMLURL::setURL(const XMLCh* const urlText) > > This Method calls > > void XMLURL::parse(const XMLCh* const urlText) > > This Method makes a pointer 'XMLCh *srcPtr' to urlText and calls (in a > loop): > > XMLPlatformUtils::fgTransService->isSpace(*srcPtr) > > This Method is defined in IconvFBSDTransService.cpp. It expects a XMLCh (which > seems to be a wchar_t) and runs > > mbstowcs( (wchar_t*) &toCheck, buf, 1 ); > > on *srcPtr, wich is really a const char. Could this be the error? > mbstowcs is MultiByteStringToWideCharString. it's a conversion routine. is this *exactly* how it's coded? mbstowcs( (wchar_t*) &toCheck, buf, 1 ); if so, fooie! i *hate* it when folks dont check return values! it returns a size_t, and viewing the man page indicates what it will return under what circumstances so, your suspicion is that it's unhappy *might* be easy to check by adding a return value i just read the man page for this function (on my linux box at work) and it's full of fascinating facts. my next suggestion would be to add a return val and see what the value is. i'd also see if toCheck is NULL. and for that matter, that buf isnt NULL either. boy, i hope this helps. you've been working so hard at this! > > > test.xml: > > > <?xml version="1.0" encoding="UTF-8"?> > > > <!DOCTYPE blah SYSTEM "test.dtd"> > > > > > > <blah> > > > <blub/> > > > <blah> > > > <blub/> > > > </blah> > > > </blah> > > > > > > test.dtd: > > > <!ELEMENT blah ((blah|blub)+)> > > > <!ELEMENT blub EMPTY> > > > > really nice trivial example! great for this sort of thing.... > > Thanks. > > > i'd step all the way thru ( it's a pain in the ass, but...) and watch what > > happens to the variables that either went NULL, or where never new'd in > > the first place.... the place where they get initialized would be the most > > interesting. you could probably grep around a bit and then just set a > > breakpoint close to where they get set up and thus avoid much 's'-ing.... > > So, I did it ;-) it's your turn ;-) > > Greets, > CK > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
