How to determine if a function (wcwidth/wcswidth) is AS- and AC-safe?

[Florian Weimer]

* Nikola Arlotti via Libc-help:

> I was on Arjun Shankar's glibc patch writing workshop on DevConf Czechia,
> and I got the patch for the bug
> https://sourceware.org/bugzilla/show_bug.cgi?id=33740 (documenting the
> functions wcwidth and wcswidth). The patch is almost ready, one question
> remains - are wcwidth and wcswidth AC- and AS-safe? Other, similar
> functions in ctype.texi are AS- and AC-safe, but I would prefer to be sure
> before submitting the patch rather than base it on vibes only (especially
> that they're defined elsewhere in the codebase).

This is a bit of a pain point.  The premise of the safety annotations is
wrong.  They are based on implementation details at the time the source
code was analyzed.  For example, getenv was marked as AS-Safe and
AC-Safe even though it never was intended to be (and the requirement to
be AS-Safe and AC-Safe continues to be problematic for us).  The current
documentation framework does not allow us to state that an interface is
not intended to be AS-Safe (or AC-Safe) when it just so happens that the
current (perhaps incomplete) implementation does not do anything that
would make it AS-Unsafe or AC-Unsafe.

The locale situation is particularly confusing because we do not even
unload locales loaded via setlocale, so there's no compelling reason why
this would not be thread-safe.

> So, question as in topic - what steps should I take while writing
> documentation to determine the safety level of functions? Is there perhaps
> any documentation I missed? Or maybe is there some heuristic I can go by?

I would use this:

@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}

I think it's currently accurate because we don't have the
acquire/release pair for cross-thread synchronization on the global
locale pointer that would be required for thread-safety.

Thanks,
Florian