[all-commits] [llvm/llvm-project] e72280: [libc] Use #undef isascii in specific header

[Roland McGrath via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: e7228062b2bb87abf762abcb77668452a1ed35d4
      https://github.com/llvm/llvm-project/commit/e7228062b2bb87abf762abcb77668452a1ed35d4
  Author: Roland McGrath <mcgrathr at google.com>
  Date:   2021-01-14 (Thu, 14 Jan 2021)

  Changed paths:
    M libc/src/ctype/isascii.h
    M libc/test/src/ctype/isascii_test.cpp
    M libc/utils/UnitTest/FuchsiaTest.h

  Log Message:
  -----------
  [libc] Use #undef isascii in specific header

Standard C allows all standard headers to declare macros for all
their functions.  So after possibly including any standard header
like <ctype.h>, it's perfectly normal for any and all of the
functions it declares to be defined as macros.  Standard C requires
explicit `#undef` before using that identifier in a way that is not
compatible with function-like macro definitions.

The C standard's rules for this are extended to POSIX as well for
the interfaces it defines, and it's the expected norm for
nonstandard extensions declared by standard C library headers too.

So far the only place this has come up for llvm-libc's code is with
the isascii function in Fuchsia's libc.  But other cases can arise
for any standard (or common extension) function names that source
code in llvm-libc is using in nonstandard ways, i.e. as C++
identifiers.

The only correct and robust way to handle the possible inclusion of
standard C library headers when building llvm-libc source code is to
use `#undef` explicitly for each identifier before using it.  The
easy and obvious place to do that is in the per-function header.
This requires that all code, such as test code, that might include
any standard C library headers, e.g. via utils/UnitTest/Test.h, make
sure to include those *first* before the per-function header.

This change does that for isascii and its test.  But it should be
done uniformly for all the code and documented as a consistent
convention so new implementation files are sure to get this right.

Reviewed By: sivachandra

Differential Revision: https://reviews.llvm.org/D94642