JDK-8313396 : Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2023-07-31
  • Updated: 2025-01-20
  • Resolved: 2025-01-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b06Fixed
Related Reports
Cloners :  
JDK-8347719 - [REDO] Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION
Relates :  
JDK-8347703 - HotSpot Style Guide needs update for deprecated attribute
Relates :  
JDK-8346987 - [lto] gtest build fails
Relates :  
JDK-8347649 - Build fails by clang17 after JDK-8313396
Relates :  
JDK-8347707 - Prefer os::snprintf instead of ::snprintf
Description
Currently, FORBID_C_FUNCTION only works for gcc like compilers, and ALLOW_C_FUNCTION acts to disable CRT warnings on Windows, where FORBID_C_FUNCTION does not work. It would be beneficial to provide a universal portable definition for both, to reduce maintenance cost and to allow the macros to work on all platforms HotSpot can be compiled for
Comments
Changeset: e0f2f4b2 Branch: master Author: Kim Barrett <kbarrett@openjdk.org> Date: 2025-01-13 18:25:42 +0000 URL: https://git.openjdk.org/jdk/commit/e0f2f4b216bc9358caa65975204aee086e4fcbd2
13-01-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22890 Date: 2024-12-29 08:11:07 +0000
29-12-2024
No -Wdeprecated-definitions warnings with LTO. (And yes, I remembered to remove the LTO suppression for g1ParScanThreadState.) And I think that makes sense. The deprecation check should be done early, during syntactic and semantic analysis, while the pragma information is still available. The link-time compilation happens after syntactic and semantic checking has been done, so it shouldn't be checking for deprecation warnings. This is different from the -Wattribute-warning, where such warnings are supposed to be generated only if there is still a reference after all optimizations (including LTO) have been applied. So the check for that is necessarily done later, and unfortunately at a phase where the suppression pragmas have not been propagated to. An effect of this difference is that with the new method a call to a forbidden function from dead code will still warn, where it wouldn't with the old method. I think that's actually a feature.
23-12-2024
I checked the new solution out briefly, and it seems like it might still fire warnings when LTO is active? I haven't tested it yet (Don't really have the time) but from what I see, the core forbidding still seems to rely on adding a poisoning attribute to global redeclaration of a forbidding function, which was what was causing grief the last time with LTO
23-12-2024
Stealing, because I think I have a solution to this. No PR just yet, but soon I think. https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:new-poison?expand=1
22-12-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/17387 Date: 2024-01-12 06:16:25 +0000
09-07-2024