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

[Martin Storsjö]

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.

// Martin