[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: Monday, May 9, 2022 12:47 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 Mon, 9 May 2022, Soft Works wrote:
> 
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> Martin Storsjö
> >> Sent: Monday, May 9, 2022 11:42 AM
> >> 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 Mon, 9 May 2022, Soft Works wrote:
> >>
> >>>
> >>>
> >>>> -----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:
> >>>>
> >>>>> 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).
> >>
> >> Indeed - for the fopen family of functions, we would need to
> duplicate
> >> all
> >> of fopen/fclose/fprintf/fwrite/fputs and whatever might happen to
> be
> >> used.
> >> So that doesn't seem worthwhile.
> >>
> >>> So I wonder whether it wouldn't make sense to deprecate this as
> >>> a public API member?
> >>
> >> I agree that it probably would be the best way forward, to
> deprecate
> >> it as
> >> a public API, without any suggested replacement. A quick googling
> >> didn't
> >> find any real use of the function outside of ffmpeg itself, I only
> >> found
> >> hits in language wrappers (which try to map every single function
> to
> >> the
> >> other language). So I think that would have minimal impact on
> others.
> >>
> >> We could then adjust the function to be a header inline function
> >> (which
> >> takes care of the duplication into all libraries), just like the
> other
> >> wchar<->utf8 functions we have in libavutil/wchar_filename.h, so we
> >> safely
> >> could use them within fftools too.
> >
> > This would sound good to me, so when nobody objects, that would be
> > the way to go IMO.
> > And in case that somebody would object, the second best option could
> > be to deprecate it for Windows only (while api differences per
> platform
> > are surely not desirable, it might still be justified for a niche
> case
> > like this).
> >
> > BTW - could it be that your original patch missed to apply the same
> for
> > libavfilter?
> 
> At the time, there were no uses of the per-library duplicated
> functions
> within libavfilter, so I didn't add it there. If we add usage of them,

There are 9 uses already and my patch adds 6. 

> would indeed need to add the same duplication logic there too. (But if
> we
> make the function entirely inline in headers, as opposed to
> avpriv_open/ff_open, we don't need to do that for use of that
> function.)

Yup.

Thanks,
softworkz