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 32F4442DE3 for ; Sun, 8 May 2022 19:48:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8BD3C68B38C; Sun, 8 May 2022 22:48:44 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E312F68A2F6 for ; Sun, 8 May 2022 22:48:37 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 248Jma0Z014075-248Jma0a014075 for ; Sun, 8 May 2022 22:48:36 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id CF176A1407 for ; Sun, 8 May 2022 22:48:36 +0300 (EEST) Date: Sun, 8 May 2022 22:48:35 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: Message-ID: <3d6a9b6b-5e8f-5ca6-4c5b-a8262db54a40@martin.st> References: MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi 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 nil- >> admirari@mailo.com >> Sent: Friday, May 6, 2022 6:08 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] >> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and >> utf8toansi >> >>>> As a matter of fact, you are. Your alternative method implies >>>> ploughing >>>> through hundreds of C files normalising path handling across the >>>> entire application, >> >>> Almost everybody here knows that this isn't true. >> >> I do not. During the review of just this particular patchset it was >> found that FFmpeg >> sometimes uses av_fopen_utf8 and sometimes just plain fopen. Plain >> fopens >> were already replaced with av_fopen_utf8 and then reverted back. >> because suddenly it turned out that av_fopen_utf8 is problematic: >> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295488.html. > > Read again. As each lib gets its own copy of file_open.c there's > no problem using av_fopen_utf8. The concern in that message was > about it being a public API that could be used by external callers. No, it's not quite as simple. Yes, each library gets its own copy of av_fopen_utf8, but fftools doesn't get its own copy. That's why it's a real problem. (Secondly, one part of the trick of giving each library its own copy of is that avpriv_open is renamed ff_open, so that it is not an exported function. But in the case of av_fopen_utf8, it's an entirely public API, so we can't hide it.) // 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".