From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id EF23D42DE3 for ; Sun, 8 May 2022 20:11:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9ACD168B315; Sun, 8 May 2022 23:11:56 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4AA1F68AE9B for ; Sun, 8 May 2022 23:11:50 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 248KBmsU014484-248KBmsV014484 for ; Sun, 8 May 2022 23:11:48 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 1724CA1407 for ; Sun, 8 May 2022 23:11:47 +0300 (EEST) Date: Sun, 8 May 2022 23:11:47 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: Message-ID: References: <3174427a-8eb7-b2c-eca4-242d8c9d32c@martin.st> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sat, 7 May 2022, Soft Works wrote: >> -----Original Message----- >> From: ffmpeg-devel 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. // 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".