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 5C11F42685 for ; Wed, 25 May 2022 18:50:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1381168B543; Wed, 25 May 2022 21:50:28 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 35A3168B4A5 for ; Wed, 25 May 2022 21:50:21 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 24PIoKMn007348-24PIoKMo007348 for ; Wed, 25 May 2022 21:50:20 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 0FCFAA142D for ; Wed, 25 May 2022 21:50:19 +0300 (EEST) Date: Wed, 25 May 2022 21:50:16 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH v7 2/3] avformat/os_support: 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-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 Wed, 25 May 2022, nil-admirari@mailo.com wrote: >> + struct win32_stat >> + { >> + _dev_t st_dev; /* ID of device containing file */ >> + _ino_t st_ino; /* inode number */ >> + unsigned short st_mode; /* protection */ >> + short st_nlink; /* number of hard links */ >> + short st_uid; /* user ID of owner */ >> + short st_gid; /* group ID of owner */ >> + _dev_t st_rdev; /* device ID (if special file) */ >> + int64_t st_size; /* total size, in bytes */ >> + int64_t st_atime; /* time of last access */ >> + int64_t st_mtime; /* time of last modification */ >> + int64_t st_ctime; /* time of last status change */ >> + }; > > Wouldn't it make sense to add a > static_assert(sizeof(struct win32_stat) == sizeof(struct _stati64)) > somewhere? > >> +static inline void copy_stat(struct _stati64 *winstat, struct win32_stat *par) >> +{ >> + par->st_dev = winstat->st_dev; >> + par->st_ino = winstat->st_ino; >> + par->st_mode = winstat->st_mode; >> + par->st_nlink = winstat->st_nlink; >> + par->st_uid = winstat->st_uid; >> + par->st_gid = winstat->st_gid; >> + par->st_rdev = winstat->st_rdev; >> + par->st_size = winstat->st_size; >> + par->st_atime = winstat->st_atime; >> + par->st_mtime = winstat->st_mtime; >> + par->st_ctime = winstat->st_ctime; >> } > > Would memcpy make more sense here? As explained elsewhere too, the explicit intent is that this is a different struct than the real _stati64 or whichever happens to be used, not necessarily identical. We don't know the exact layout of the real stat struct (and technically, different C runtimes, e.g. msvcrt.dll, msvcr100.dll, msvcr120.dll, UCRT, could all have different layouts/sizes), and it's brittle to try to guess/mimic it. So instead of trying to mimic it, we just make our own (which is what ends up used in the calling libavformat code) - our wrapper then explicitly uses one from the C runtime (which we don't know the size/layout of), and we just copy it field by field into the one we expose to the caller. This could use any random layout, as long as it contains the subset of fields from stat that we actually use anywhere. And if we wanted a static assert, the only relevant assert would be to make sure that our wrapper struct's fields are as large as, or larger, than the ones that the original stat returns. // 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".