RFR: 8214976: Warn about uses of functions replaced for portability

[David Holmes]

On Wed, 1 Jun 2022 22:02:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this new mechanism for "poisoning" uses of certain functions,
> along with marking specific uses as still being permitted.  One use for this
> is to discourage use of external library functions for which HotSpot provides
> extended versions or portability shims.  Another is to prevent uses of certain
> functions considered "insecure", promoting alternatives or requiring strong
> scrutiny.
> 
> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
> implementations.  Comments in the code describe the details.  For some
> compilers we didn't find any features that would permit such poisoning.  As a
> result, only shared code has complete coverage.
> 
> For gcc and clang we use an attribute that warns about references to an
> annotated function, and scoped suppression of that warning.  This
> functionality is provided since gcc9 and clang14.  (I haven't tested with
> clang; version 14 is more recent than I have access for.  But the docs
> describe an explicit match to the gcc functionality.)
> 
> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
> deprecation annotations and scoped suppression of the consequent warnings
> seemed plausible, but ran into problems.  (See comments in code for details.)
> But we provide scoped suppression of deprecation warnings anyway.  Many of the
> functions we'd poison are already conditionally deprecated under the control
> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
> we've removed or annotated all calls associated with one of those macros we
> can remove the macro from our builds, preventing new uses from creeping into
> unshared code.
> 
> The aix-ppc port doesn't provide poisoning support.  The version of clang used
> by xlclang is older than the warning attribute and suppression.
> 
> Along with the new mechanisms, a few functions are poisoned by this change.
> More functions can be added as folks have time to address their uses.
> 
> The poisoning declarations are in globalDefinitions.hpp, since the signatures
> may use types that have platform-specific definitions or locations that are
> provided within that header.  That header is included (directly or indirectly)
> nearly everywhere, so provides good coverage.
> 
> The rest of the changes are to address existing uses of the newly forbidden
> functions, either using something else or annotating them as permitted uses.

Hi Kim,
This seems fine to me.
Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8982