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

["Martin Storsjö" <martin@martin.st>]

On Mon, 9 May 2022, Soft Works wrote:

>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Martin Storsjö
>> Sent: Monday, May 9, 2022 11:42 AM
>> To: FFmpeg development discussions and patches <ffmpeg-
>> devel@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@ffmpeg.org> On Behalf Of
>>>> Martin Storsjö
>>>> Sent: Sunday, May 8, 2022 10:12 PM
>>>> To: FFmpeg development discussions and patches <ffmpeg-
>>>> devel@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, we 
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.)

// 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-request@ffmpeg.org with subject "unsubscribe".