Re: string word-at-a-time and atomic.h FAQ on twitter

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@libc.org> [2016-01-08 17:59:51 -0500]:
> On Sat, Jan 09, 2016 at 01:39:10AM +0300, Alexander Cherepanov wrote:
> > >>>>this takes care of oob access, but the bytes outside the passed
> > >>>>object might change concurrently i.e. strlen might introduce a
> > >>>>data race: again this is a problem on the abstract c language
> > >>>>level that may be solved e.g. by making all accesses to those
> > >>>>bytes relaxed atomic, but user code is not under libc control.
> > >>>>in practice the code works if HASZERO reads the word once so it
> > >>>>does arithmetics with a consistent value (because the memory
> > >>>>model of the underlying machine does not treat such race
> > >>>>undefined and it does not propagate unspecified value bits nor
> > >>>>has trap representations).
> > >>>
> > >>>Indeed, this seems like less of a practical concern.
> > >>
> > >>HASZERO reads the word twice so this should be a problem for
> > >>unoptimized code on big-endian platforms.
> > >
> > >The number of abstract-machine reads is irrelevant unless we use
> > >volatile here. A good compiler will always reduce it to one read, and
> > >a bad compiler is always free to turn it into multiple reads.
> > 
> > Ok, I'll reformulate: is compiling musl on a big-endian platform
> > with optimizations turned off officially supported?
> 
> Yes, and I don't see why you expect this case to break due to data
> race issues.

i didnt think it through, just assumed changing bits
would ruin the computation.

but it seems if the zero byte is unchanged then other
bits can arbitrarily change between the two evaluations
of x in

#define HASZERO(x) ((x)-ONES & ~(x) & HIGHS)

and the predicate is still true

..unless some silly code transformation is applied
like x -> x+x-x