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

[Kim Barrett]

On Thu, 2 Jun 2022 13:06:18 GMT, David Holmes <dholmes 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.

Thanks for reviews @dholmes-ora , @tschatzl , and @coleenp .

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

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