<sys/membarrier.h>

[Adhemerval Zanella Netto]

On 10/07/26 11:37, enh wrote:
> On Thu, Jul 9, 2026 at 7:44 PM Arsen Arsenović <aarsenovic@baylibre.com> wrote:
>>
>> Florian Weimer <fweimer@redhat.com> writes:
>>
>>>> yeah, "all the choices suck". varargs has caused android (and android
>>>> developers) pain in the past too, so i'm tempted to go for three
>>>> arguments, but then callers are going to need an #if to support musl,
>>>> at which point everyone may as well have stuck with syscall() :-(
>>>
>>> We can provide C++ overloads for two and three arguments.  With GCC, we
>>> can use __builtin_va_arg_pack and __builtin_va_arg_pack_len to emulate
>>> that in C.  It's not supported by Clang.
>>
>> That may not be, but
>> https://clang.llvm.org/docs/AttributeReference.html#overloadable is.
> 
> yeah, bionic uses that to get round the unsigned/signed conversion
> warnings with ioctl() so we could use it to have two membarrier()s
> (it's also used throughout the clang fortify implementation, but
> that's unrelated). i suppose we could even do something like the
> fortify check for open() with O_CREAT or O_TMPFILE but no mode. that's
> by far the most verbose way we could possible write membarrier() in
> the headers, but maybe the best option?
glibc also uses clang overloadable to implement the fortify sources. It would
require to expose some definitions only used on fortify to generic usage,
and it is unclear how to support compilers that do not support
neither __va_arg_pack_len nor attribute overloadable (maybe only support
3-arguments in this case).