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 02E2442DA0 for ; Sat, 7 May 2022 17:33:27 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B9B9A68B3B1; Sat, 7 May 2022 20:33:24 +0300 (EEST) Received: from msg-6.mailo.com (ip-16.mailobj.net [213.182.54.16]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4B7C468A318 for ; Sat, 7 May 2022 20:33:18 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1651944796; bh=sY0VCU0s6ZyWjc2Ru5xZ95o9S+J8MYAiKN1mWyXIoW0=; h=X-EA-Auth:From:To:Date:Subject:MIME-Version:X-Mailer:Message-ID: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FWwuvo/4B5KDQmEEJLeg5u6498O2FmFoYpjxj5HQb1UEWz5cFl8dUsD+NPkwci1nH ELGBvnnRruWDFOIUhi1bxhj8yNZb241LZSTe06qcK+AXyeCxlMNWxy3v+nbqSJX0Ti KIy8gsQVdoJG/3kb+wD45+ht7EEIteHlcaslXxcw= Received: by www-7.mailo.com with http webmail; Sat, 7 May 2022 19:33:16 +0200 (CEST) X-EA-Auth: Wi5hfxdRjcZk8Otlrm2SzC8g5ukbkHCi6qfI9tv19/9l1UUKsiXKv77vEMkVBE0fC0q/zKzTkoatbP1WPEyTYfUca0h8Tog4 From: nil-admirari@mailo.com To: ffmpeg-devel@ffmpeg.org Date: Sat, 7 May 2022 19:33:16 +0200 (CEST) X-Priority: 3 MIME-Version: 1.0 X-Mailer: COMS/EA21.01/r20220415 Message-ID: In-Reply-To: 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: You have completely ignored my question, haven't you? Here it is again: >> Is there a Path struct, analogous to LLVM class, that all of FFmpeg is using? >> Or FFmpeg isn't using any special structs and paths are indistinguishable >> from ordinary strings? > 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. av_fopen_utf8 wasn't mentioned because it has a particular problem. It was mentioned to say that >> FFmpeg sometimes uses av_fopen_utf8 and sometimes just plain fopen i.e. there is no standardised path handling. > That's the pending issue with your 4/6 which is probably ok otherwise. It's not an issue with my patch. It's something that was already there, and is retained not to break something. > 3/6 is pointless without 5/6 It is pointless in one and only one case: no long path support arrives ever. Please reread: > MAX_PATH-sized buffers simply do not work with long paths, even the ones > that start with \\?\. You will still have to replace them with dynamically > allocated buffers. And that's what the majority of this patch-set > is about, not about the manifest. > 2/6 is pointless without 6/6 Wrong. 6/6 enables process-wide UTF-8. utf8toansi allocates buffers of necessary size instead of using MAX_PATH. utf8toansi doesn't care whether ansi is UTF-8 or a legacy encoding. > 1/6 remaining bits can be inlined in 4/6 Why should they? Are two calls to WideCharToMultiByte + allocation more readable than a single call to wchartoansi? _______________________________________________ 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".