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 42AA9430FA for ; Fri, 20 May 2022 17:52:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 187C568B482; Fri, 20 May 2022 20:51:59 +0300 (EEST) Received: from msg-4.mailo.com (ip-15.mailobj.net [213.182.54.15]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4BA6568B2A8 for ; Fri, 20 May 2022 20:51:52 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1653069111; bh=lKsn/KT9hcYbuOl6/1Rl/Ks+clqCdJSuUAUKRv8ew58=; h=X-EA-Auth:From:To:Date:Subject:MIME-Version:X-Mailer:Message-ID: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YiVDFQCWYiVh5uklYaM1TiwADgQcwyAgOZ6v6JrWvNKVrm/GVdMgpBbgGsgH+lu8R S1ttfpT0axEKR0KE/Mp44yXUjEiUoBWO10mebhcg91CTbdaaF35Rna3UCZ8kg/dNb0 L9xeS1piELpqx6w12cOG2s8XiTggMplkk6SEDQEs= Received: by www-7.mailo.com with http webmail; Fri, 20 May 2022 19:51:51 +0200 (CEST) X-EA-Auth: T+IUO/5bMK4/jVrkkHGMBIOVSWn2xffAyt/bTmQUhn9tg4xZdWQ7FnPqPML2z8qRtSW1SOLqkqUwV5w+HKS8/WYGq6TuI0Ec From: nil-admirari@mailo.com To: ffmpeg-devel@ffmpeg.org Date: Fri, 20 May 2022 19:51:51 +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 v2 1/2] avutil/wchar_filename, file_open: Support long file names 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-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: > Yes, that's true. But there are hundreds of other things someone could > define which makes compilation fail. Doesn't mean that yet another such thing should be added by incorrectly redefining structs already defined correctly by system headers. > Probably you didn't spot it. It's already there: > # define stat win32_stat I'm actually wondering how does it even compile. All stat structs in code become struct win32_stat, and all calls to stat become calls to win32_stat, which in turn wraps _wstati64. But _wstati64 does not accept struct win32_stat*, it accepts struct _stati64*. Content of these structs is probably identical, but it should not matter: C is typed nominally, not structurally. > I don't want to say that I'd consider this to be a great solution. > But the problem is that the function and struct names are identical > and when we want to re-define/map the function, we also need to > provide a struct of that name because the macro-replacement can't > work selectively. Doesn't mean that the should be named identically in FFmpeg code. Naming a struct stat and a function avpriv_stat is a reasonable choice. You can even define avpriv_stat with parameters the way fstat is defined: #ifdef _WIN32 #define avpriv_stat(f,s) win32_stat((f), (s)) #else #define avpriv_stat(f,s) stat((f), (s)) #endif _______________________________________________ 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".