On Mon, 9 May 2022, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
Martin Storsjö
Sent: Sunday, May 8, 2022 10:12 PM
To: FFmpeg development discussions and patches <ffmpeg-
de...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
