Re: [FFmpeg-devel] [PATCH] compat/atomics/win32: improve similarity to stdatomic.h

["Rémi Denis-Courmont" <remi@remlab.net>]

Le mercredi 5 avril 2023, 18:26:29 EEST Frank Plowman a écrit :
> Some preliminary info:
> * The win32 atomic compatibility header is based on VLC's (c91e72ed52). This
> 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/ce150f3849cebe97bc7fc028674d3
> 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-bit 
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- and
> 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 as 
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".