This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MT-safe annotations for gcvt and related functions

On 12/18/2014 06:41 AM, Alexandre Oliva wrote:
> 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.

I think this contradicts glibc's goal of âno internal data racesâ that
was discussed some time ago.  Maybe add this aspect as well?  Then it
seems I fine addition to me.

Florian Weimer / Red Hat Product Security

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]