From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9073 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: string word-at-a-time and atomic.h FAQ on twitter Date: Sat, 9 Jan 2016 02:40:49 +0100 Message-ID: <20160109014048.GP23362@port70.net> References: <20160105164640.GL23362@port70.net> <20160105175040.GA238@brightrain.aerifal.cx> <5690315B.5010206@openwall.com> <20160108220535.GO238@brightrain.aerifal.cx> <56903A8E.90802@openwall.com> <20160108225951.GP238@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452303667 12019 80.91.229.3 (9 Jan 2016 01:41:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 01:41:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9086-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jan 09 02:41:06 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aHiWd-0005vY-9V for gllmg-musl@m.gmane.org; Sat, 09 Jan 2016 02:41:03 +0100 Original-Received: (qmail 22209 invoked by uid 550); 9 Jan 2016 01:41:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22191 invoked from network); 9 Jan 2016 01:41:00 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20160108225951.GP238@brightrain.aerifal.cx> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9073 Archived-At: * Rich Felker [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