┌───────────────────────────┬───────────────┬────────────────────┐
       │Interface                  │ Attribute     │ Value              │
       ├───────────────────────────┼───────────────┼────────────────────┤
       │getaddrinfo()              │ Thread safety │ MT-Safe env locale │
       ├───────────────────────────┼───────────────┼────────────────────┤
       │freeaddrinfo(),            │ Thread safety │ MT-Safe            │
       │gai_strerror()             │               │                    │
       └───────────────────────────┴───────────────┴────────────────────┘


       MT-Safe
              MT-Safe or Thread-Safe functions are safe to call in the
              presence of other threads.  MT, in MT-Safe, stands for
              Multi Thread.

              Being MT-Safe does not imply a function is atomic, nor
              that it uses any of the memory synchronization mechanisms
              POSIX exposes to users.  It is even possible that calling
              MT-Safe functions in sequence does not yield an MT-Safe
              combination.  For example, having a thread call two MT-
              Safe functions one right after the other does not
              guarantee behavior equivalent to atomic execution of a
              combination of both functions, since concurrent calls in
              other threads may interfere in a destructive way.

              Whole-program optimizations that could inline functions
              across library interfaces may expose unsafe reordering,
              and so performing inlining across the GNU C Library
              interface is not recommended.  The documented MT-Safety
              status is not guaranteed under whole-program optimization.
              However, functions defined in user-visible headers are
              designed to be safe for inlining.


   Other safety remarks
       Additional keywords may be attached to functions, indicating
       features that do not make a function unsafe to call, but that may
       need to be taken into account in certain classes of programs:

       locale Functions annotated with locale as an MT-Safety issue read
              from the locale object without any form of
              synchronization.  Functions annotated with locale called
              concurrently with locale changes may behave in ways that
              do not correspond to any of the locales active during
              their execution, but an unpredictable mix thereof.

              We do not mark these functions as MT-Unsafe, however,
              because functions that modify the locale object are marked
              with const:locale and regarded as unsafe.  Being unsafe,
              the latter are not to be called when multiple threads are
              running or asynchronous signals are enabled, and so the
              locale can be considered effectively constant in these
              contexts, which makes the former safe.

       env    Functions marked with env as an MT-Safety issue access the
              environment with getenv(3) or similar, without any guards
              to ensure safety in the presence of concurrent
              modifications.

              We do not mark these functions as MT-Unsafe, however,
              because functions that modify the environment are all
              marked with const:env and regarded as unsafe.  Being
              unsafe, the latter are not to be called when multiple
              threads are running or asynchronous signals are enabled,
              and so the environment can be considered effectively
              constant in these contexts, which makes the former safe.