From patchwork Thu Dec 18 05:41:42 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 4333 Received: (qmail 16815 invoked by alias); 18 Dec 2014 05:41:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 16803 invoked by uid 89); 18 Dec 2014 05:41:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com From: Alexandre Oliva To: Florian Weimer Cc: GNU C Library Subject: Re: MT-safe annotations for gcvt and related functions References: <548ACAD9.6010906@redhat.com> <549089A1.4030705@redhat.com> Date: Thu, 18 Dec 2014 03:41:42 -0200 In-Reply-To: <549089A1.4030705@redhat.com> (Florian Weimer's message of "Tue, 16 Dec 2014 20:36:01 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 On Dec 16, 2014, Florian Weimer wrote: > On 12/16/2014 08:25 PM, Alexandre Oliva wrote: >> AFAICT, whereas __printf_fp does access _NL_CURRENT multiple times, but >> they all access the same locale object, because they all use the result >> of dereferencing the pointer to the current locale a single time, as a >> result of compiler optimization, and as such it doesn't mandate the >> “locale” annotation, although it certainly wouldn't hurt to add it. > Interesting, I wasn't aware that the rules for these annotations work > out that way. I thought all access to the global locale object were > racy. Here's a patch that appends some more comments to the definition of locale discussing this point. Ok to install? for ChangeLog * manual/intro.texi (locale): Expand, in comments, rationale on not marking single dereferences of the locale pointer. --- manual/intro.texi | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/manual/intro.texi b/manual/intro.texi index d4045f2..6cd5776 100644 --- a/manual/intro.texi +++ b/manual/intro.texi @@ -730,6 +730,22 @@ constant in these contexts, which makes the former safe. @c locale multiple times may invoke all sorts of undefined behavior @c because of the unexpected locale changes. +@c The “multiple times” above is relevant. Functions that dereference +@c the locale pointer only once, even if to access the locale object +@c multiple times (_NL_CURRENT's design enables this sort of compiler +@c optimization, and current compilers can be counted on to perform +@c them), will behave consistently with that one locale object they +@c reference throughout. So, we will generally not annotate such +@c functions with the @code{locale} keyword, even though calling such a +@c function multiple times in sequence will not ensure the same locale +@c object is used. + +@c We have to take care, however, of our functions that *internally* +@c call such functions multiple times: these have to be marked with +@c locale, because each internal call may end up using a different +@c locale and thus the internal calling function will behave +@c inconsistently overall. + @item @code{env} @cindex env