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 D2763455FE for ; Sun, 9 Apr 2023 09:02:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 552446807FC; Sun, 9 Apr 2023 12:02:44 +0300 (EEST) Received: from ursule.remlab.net (vps-a2bccee9.vps.ovh.net [51.75.19.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D2A816807FC for ; Sun, 9 Apr 2023 12:02:37 +0300 (EEST) Received: from ursule.remlab.net (localhost [IPv6:::1]) by ursule.remlab.net (Postfix) with ESMTP id 10FF3C009A for ; Sun, 9 Apr 2023 12:02:37 +0300 (EEST) Received: from noel.remlab.net ([2a01:cb0c:813:a400:b1c5:8627:2f63:2faf]) by ursule.remlab.net with ESMTPSA id Yv0VAy1/MmQdciAAwZXkwQ (envelope-from ) for ; Sun, 09 Apr 2023 12:02:37 +0300 From: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont To: ffmpeg-devel@ffmpeg.org Date: Sun, 09 Apr 2023 11:59:07 +0300 Message-ID: <10443116.5V0ZpFB1Yi@noel> Organization: Remlab In-Reply-To: <20230405152629.35740-1-post@frankplowman.com> References: <20230405152629.35740-1-post@frankplowman.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] compat/atomics/win32: improve similarity to stdatomic.h 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Le mercredi 5 avril 2023, 18:26:29 EEST Frank Plowman a =E9crit : > Some preliminary info: > * The win32 atomic compatibility header is based on VLC's (c91e72ed52). T= his > patch makes the header more in line with what it was before they got rid = of > this way of doing things: > https://code.videolan.org/videolan/vlc/-/blob/ce150f3849cebe97bc7fc028674= d3 > c7f8c73f64d/include/vlc_atomic.h > * The Windows API does not support atomic > operations on 8-bit types and only has functions for atomic operations on > 16-bit types on Windows Desktop. FWIW, Windows atomic wait/notify system call functions support 8- and 16-bi= t = types, so I would expect that there is a mean to perform atomic load/store/ exchange/compare-exchange too. > * Makes atomic types the same size as their non-atomic counterparts. > Previously, all atomic types were intptr_t to get around the lack of 8- a= nd > 16-bit atomic operations. This could lead to overreads. Now, each atomic > type is the same size as its non-atomic counterpart, in line with the C11 > specification. There are no requirements in C11 that atomic variables have the same size a= s = their non-atomic-qualified equivalent. It is not clear what you mean here. I also don't know what you mean by overread. If you don't want values to = overflow their specified boundaries, the "correct" approach is to mask the = excess bits (like how compilers implement small atomics on RISC-V). _______________________________________________ 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".