> -----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: > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > >> Andreas Rheinhardt > >> Sent: Saturday, May 7, 2022 6:32 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object > >> sharing issue on Windows > >> > >> Soft Works: > >>> > >>> > >>>> -----Original Message----- > >>> > >>> I don't have experience with that kind of setup, but I would have > >>> thought that with separate CRTs, you could already get into > trouble > >>> when you would allocate a string in the main application which > >>> you pass to any of the DLL's APIs and which might get freed by > >>> the DLL at a later time - doesn't that fail? > >>> > >> > >> Whenever any of the FFmpeg libraries takes ownership of a string or > >> another buffer*, we require it to be freeable with av_free > (typically > >> by > >> saying that it needs to be allocated with the av_malloc family of > >> functions). So all allocs and frees have to happen in libavutil. > This > >> is > >> also true for all the other allocations directly performed by the > the > >> FFmpeg libraries. > >> (The only exceptions to this are AVBuffer(Ref)s which allow users > to > >> use > >> custom allocators and destructors.) > > > > 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). So I wonder whether it wouldn't make sense to deprecate this as a public API member? Kind regards, 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".