From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7796 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale change ideas Date: Wed, 27 May 2015 16:37:38 -0400 Message-ID: <20150527203738.GO17573@brightrain.aerifal.cx> References: <20150527031208.GA5255@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 1432759080 24132 80.91.229.3 (27 May 2015 20:38:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 20:38:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7808-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 27 22:37:55 2015 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 1Yxi5J-0008GQ-Mp for gllmg-musl@m.gmane.org; Wed, 27 May 2015 22:37:53 +0200 Original-Received: (qmail 19506 invoked by uid 550); 27 May 2015 20:37:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19485 invoked from network); 27 May 2015 20:37:51 -0000 Content-Disposition: inline In-Reply-To: <20150527031208.GA5255@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7796 Archived-At: On Tue, May 26, 2015 at 11:12:08PM -0400, Rich Felker wrote: > Just some ideas I want to put in writing and put out for discussion: > > Implementing a static all-C locale_t object (and, if we make C locale > byte-based, also an all-C.UTF-8 one) returned by newlocale when > possible. This would ensure that uses of newlocale "C" for robustness Done; see commit aeeac9ca5490d7d90fe061ab72da446c01ddf746. > Eliminating the messages_name field from the locale struct. I don't Done; see commit 61a3364d246e72b903da8b76c2e27a225a51351e. This also made handling of LC_CTYPE and LC_NUMERIC uniform with the rest of the categories rather than special-cased. > Handling non-synchronized reads of locale categories. The cat[] This still needs to be reviewed. There is a barrier (due to UNLOCK) between the writes to a new __locale_map object (which is immutable once it's written) and storing that object's address anywhere. It's not clear to me whether any further synchronization is necessary. It's not needed for archs with strong memory order, and I'm fairly sure it should not be needed for archs with dependency ordering, but I'm not sure if this covers everything. The case to worry about is where the new object gets allocated in memory that happens to already be cached (because it was used then freed) by another thread, and whether that thread might read stale data after obtainin/reading the pointer to it. Anyone know if this is a real possibility, and if there are good mitigations without putting a barrier at the point of read? (This is surely related to the consume-order stuff everybody is so fond of discussing and arguing about these days... :) Rich