[FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows
Martin Storsjö
martin at martin.st
Mon May 9 12:41:39 EEST 2022
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
More information about the ffmpeg-devel
mailing list