On Sat, 7 May 2022, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
Andreas Rheinhardt
Sent: Saturday, May 7, 2022 6:32 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
sharing issue on Windows
Soft Works:
-----Original Message-----
I don't have experience with that kind of setup, but I would have
thought that with separate CRTs, you could already get into trouble
when you would allocate a string in the main application which
you pass to any of the DLL's APIs and which might get freed by
the DLL at a later time - doesn't that fail?
Whenever any of the FFmpeg libraries takes ownership of a string or
another buffer*, we require it to be freeable with av_free (typically
by
saying that it needs to be allocated with the av_malloc family of
functions). So all allocs and frees have to happen in libavutil. This
is
also true for all the other allocations directly performed by the the
FFmpeg libraries.
(The only exceptions to this are AVBuffer(Ref)s which allow users to
use
custom allocators and destructors.)
Ah yes of course, thanks for the explanation. I still wonder whether
there aren't any other issues when multiple CRTs are being used?
Or are the file IO APIs the only "weak" point with regards to
multiple CRTs being used?
In the case of ffmpeg, yes.
For generic library design, you'd have an issue anywhere where you pass
CRT resources around - file descriptors from open, FILE*, and indeed as
you mentioned - allocating and freeing memory with malloc/free in
different DLLs. But as long as the library design is such that you don't
hand over ownership of allocations and don't pass such objects across DLL
boundaries, there's no issue.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
