[FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Martin Storsjö
> Sent: Sunday, May 8, 2022 10:12 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
> sharing issue on Windows
> 
> On Sat, 7 May 2022, Soft Works wrote:
> 
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Saturday, May 7, 2022 6:32 AM
> >> To: ffmpeg-devel at 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.

Yup, understood. I thought there would be many more, but I realized
that those "many more" I thought about are all C++ things, not C.

So, putting this all together, I agree that the existence of 
av_fopen_utf8 (as a public API!) is rather unfortunate. To make this 
consistent, it would be necessary to provide av_ equivalents to
all the file APIs as well (but there are quite a few).

So I wonder whether it wouldn't make sense to deprecate this as
a public API member?

Kind regards,
softworkz