> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Martin Storsjö > Sent: Monday, May 9, 2022 12:47 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 Mon, 9 May 2022, Soft Works wrote: > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > >> Martin Storsjö > >> Sent: Monday, May 9, 2022 11:42 AM > >> 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 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. > > > > 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 _______________________________________________ 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".
