[
http://issues.apache.org/jira/browse/XERCESC-1378?page=comments#action_61100 ]
Nikolay Ognyanov commented on XERCESC-1378:
-------------------------------------------
I think I understand now where the confusion came
from. I respect your position even though I do not
share it but if this is the intended use of adoptBufer
then at least documentation should be fixed because it
clearly claims something quite different. Here is a
quote from API documentation for MemBufInputSource:
adoptBuffer Indicates whether this object should
adopt the buffer (i.e. make a copy of it)
or just use it in place.
This is exactly what caused segfaults in our code -
a coder (after looking at the documentation) believed
that the class creates and destroys a copy of the
buffer if adoptBuffer is true and so did delete the
buffer for a second time. Rippples of this went
through several levels of method invocations and data
structures and thus became "magic" and ended up with
a more paranoid person (myself) chasing the issue
down to the source of MemBufInputSource.
BTW - Xerces C++ is a great product and we value it
very much. So thank you.
> wrong string destruction in MemBufInputSource::~MemBufInputSource()
> -------------------------------------------------------------------
>
> Key: XERCESC-1378
> URL: http://issues.apache.org/jira/browse/XERCESC-1378
> Project: Xerces-C++
> Type: Bug
> Components: SAX/SAX2
> Versions: 2.6.0
> Environment: Any
> Reporter: Nikolay Ognyanov
>
> MemBufInputSource::~MemBufInputSource()
> {
> if (fAdopted)
> delete [] (XMLByte*)fSrcBytes;
> }
> This seems terribly wrong. Constructor initializes fSrcBytes
> with its argument srcDocBytes and this never changes, so the
> original argument string is deleted here and not a copy of it.
> Actual creation and destruction of a copy if fAdopted is set
> is handled in BinMemInputStream which is instantiated in
> MemBufInputSource::makeStream(). Therefore the code quoted
> above should be removed from the destructor and it should do
> nothing.
> Regards
> Nikolay
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
