Re: [MTASCsft PATCH 07/??] MT-, AS- and AC-Safety docs: manual/ctype.texi

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/30/2014 03:40 PM, Alexandre Oliva wrote:
> On Jan 30, 2014, Alexandre Oliva <aoliva@redhat.com> wrote:
> 
>> On Jan 30, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
>>> On 01/23/2014 01:48 PM, Alexandre Oliva wrote:
>>>> This patch has much of the vestigial records that glocale (now
>>>> @mtslocale) was regarded as an MT-Safety problem.
>  
>>> One nits. See below. We can't rely on optimization IMO.
>  
>> We don't.  We rely on locale being const, but the elaborate rationale
>> was from before we decided that.  Optimization could make this safe even
>> if locale wasn't constant, so we could drop the @mtslocale note if we
>> were to require optimization.
> 
> How about these incremental changes to islower, wctype and iswalnum,
> respectively?

Looks good to me.

> diff --git a/manual/ctype.texi b/manual/ctype.texi
> index 5bfbcec..2d73d4e 100644
> --- a/manual/ctype.texi
> +++ b/manual/ctype.texi
> @@ -72,7 +72,10 @@ These functions are declared in the header file @file{ctype.h}.
>  @c thread-local memory the (indirect) pointer to the ctype array, which
>  @c may involve one word access to the global locale object, if that's
>  @c the active locale for the thread, and the array, being part of the
> -@c locale data, is undeletable, so there's no thread-safety issue.
> +@c locale data, is undeletable, so there's no thread-safety issue.  We
> +@c might want to mark these with @mtslocale to flag to callers that
> +@c changing locales might affect them, even if not these simpler
> +@c functions.
>  Returns true if @var{c} is a lower-case letter.  The letter need not be
>  from the Latin alphabet, any alphabet representable is valid.
>  @end deftypefun
> @@ -336,9 +339,12 @@ This type is defined in @file{wctype.h}.
>  @c should the global locale object change while active, the compiler can
>  @c and does combine them all into a single dereference that resolves
>  @c once to the LCTYPE locale object used throughout the function, so it
> -@c is safe in practice, if not in theory.  Ideally we'd explicitly save
> -@c the resolved locale_data object to make it visibly safe instead of
> -@c safe only under compiler optimizations.
> +@c is safe in (optimized) practice, if not in theory, even when the
> +@c locale changes.  Ideally we'd explicitly save the resolved
> +@c locale_data object to make it visibly safe instead of safe only under
> +@c compiler optimizations, but given the decision that setlocale is
> +@c MT-Unsafe, all this would afford us would be the ability to not mark
> +@c this function with @mtslocale.
>  The @code{wctype} returns a value representing a class of wide
>  characters which is identified by the string @var{property}.  Beside
>  some standard properties each locale can define its own ones.  In case
> @@ -391,12 +397,13 @@ standard classes.
>  @safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
>  @c The implicit wctype call in the isw* functions is actually an
>  @c optimized version because the category has a known offset, but the
> -@c wctype is equally safe when optimized, unsafe if not optimized.
> -@c Since it's not a macro, and we always optimize, it's fine.  The test
> -@c whether wc is ASCII to use the non-wide is* macro/funciton doesn't
> -@c bring any other safety issues: the test does not depend on the
> -@c locale, and each path after the decision resolves the locale object
> -@c only once.
> +@c wctype is equally safe when optimized, unsafe with changing locales
> +@c if not optimized (thus @mtslocale).  Since it's not a macro, we
> +@c always optimize, and the locale can't change in any MT-Safe way, it's
> +@c fine.  The test whether wc is ASCII to use the non-wide is*
> +@c macro/function doesn't bring any other safety issues: the test does
> +@c not depend on the locale, and each path after the decision resolves
> +@c the locale object only once.
>  This function returns a nonzero value if @var{wc} is an alphanumeric
>  character (a letter or number); in other words, if either @code{iswalpha}
>  or @code{iswdigit} is true of a character, then @code{iswalnum} is also
>