RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION [v6]

[Kim Barrett]

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - add permit wrapper for strdup and use in aix
 - remove os-specific posix forwarding headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/b774f14c..000aca91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22890&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22890&range=04-05

  Stats: 100 lines in 6 files changed: 6 ins; 92 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22890.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22890/head:pull/22890

PR: https://git.openjdk.org/jdk/pull/22890