Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Jan 2016 20:03:56 +0100
From: Szabolcs Nagy <>
Subject: Re: atomic.h cleanup

* Jens Gustedt <> [2016-01-11 18:12:29 +0100]:
> Am Montag, den 11.01.2016, 17:35 +0100 schrieb Markus Wichmann:
> > OTOH, maybe we simply shouldn't write synchronisation primitives
> > ourselves and instead use the ones provided by GCC (and let other
> > compilers suck on a salty sausage, if they don't support those
> > primitives).
> I think on the long run we should use C11 atomics and leave the dirty
> work to the compiler writers. To my experience they do good work with
> that now, the assembler they produce looks nice.

yes but old compilers had various bugs on various targets.

> My stdatomic library is sitting there, ready to integrate into
> musl. It solves the problem of backwards compatibility for all
> compilers that that implement the __sync builtins. (gcc and clang with
> very old version numbers.)

i think simpler compilers like pcc, cparser, tcc
dont implement that.

if musl moves to compiler builtins then i'd
like to have a possibility to compile atomic
primitives as a separate tu

> Last time I looked, all usages but one of atomic operations in musl
> are clean. If an atomic operation is used for a data a some point,
> atomic operations are used in all other places. So moving to
> _Atomic(int) would be a option. (Basically this would be `volatile
> int*` => `_Atomic(int)`, IIRC).

pthread_once_t and pthread_spinlock_t are
publicly visibles type (without volatile and

i dont think we can fix those without abi

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.