Date: Wed, 27 May 2015 16:37:38 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Locale change ideas 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
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.