Валерий Польских wrote:
> PdfInputDevice::PdfInputDevice( const char* pszFilename )
>
> - - -
>
> m_pStream = static_cast< std::istream* >( new
> std::istringstream( std::string( pBuffer, lLen), std::ios::binary ) );
>
> if( !m_pStream || !m_pStream->good() )
>
> {
>
> PODOFO_RAISE_ERROR( ePdfError_FileNotFound );
>
> }
>
> m_StreamOwned = true;
>
>
>
> If m_pStream != NULL and m_pStream->good() == false
>
> memory allocation was occurred. But due to raising error in constructor
> m_StreamOwned = false
>
> and destructor is not called.
Good catch. These "may own" classes get tricky, since they can't use
more reliable memory management tools like auto_ptr or direct
class-level membership.
> Same situation in PdfInputDevice::PdfInputDevice( const char* pBuffer, long
> lLen )
>
>
>
>
>
> 2. PdfOutputStream.h (170)
>
>
>
> inline char* PdfMemoryOutputStream::TakeBuffer()
>
> {
>
> char* pBuffer = m_pBuffer;
>
> m_pBuffer = NULL;
>
> return pBuffer;
>
> }
>
>
>
> Destructor don't free memory. And this allocation is performed repeatedly.
I think that's by design, though Dom would know. The function passes
ownership of the returned pointer to the caller. This should be made
clear in the documentation.
If you've found a leak in practical use, then it's probably caused by
the code using this function not properly taking ownership of and
disposing of the buffer.
--
Craig Ringer
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
