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 Christian Kruse <ck...@wwwtech.de> on 2002/03/01 00:50:27 UTC
Re: Xerces-C on FreeBSD 4.5
Hi,
On Thu, 28 Feb 2002 12:40:49 -0800 (PST)
John Utz <ut...@singingfish.com> 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?
> > 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: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by John Utz <ut...@singingfish.com>.
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 <ut...@singingfish.com> 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: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org