RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION
Kim Barrett
kbarrett at openjdk.org
Sun Dec 29 11:27:34 UTC 2024
On Sun, 29 Dec 2024 08:45:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:
> Overall nice change, my only complaint is that to know which FORBID macro to use (IMPORTED, NORETURN, etc), you have to delve into implementation details to select the right one. That quickly becomes confusing. But unfortunately all the other approaches thus far have failed, so there aren't really any alternatives that are any better than this approach
Unfortunately, I couldn't find any way to determine whether IMPORTED or not
other than trial and error. One would think this might be documented
somewhere, but I didn't find anything.
Whether to use a NORETURN variant seems pretty straightforward. It would be
better if we could just say (for example)
FORBID_C_FUNCTION([[noreturn]] void exit(int), "use os::exit")
But that doesn't work both because of the clang weirdness, and because all
attributes must preceed the Windows dllimport spec.
We'll have to come up with something new if we ever want to forbid a function
that has other attributes that we need to mention. I'm hoping that won't
happen, but I haven't (yet) gone through any secure coding guidelines looking
for additional functions to forbid.
One option would be to have distinct arguments for the signature, like we do
for JNI/JVM entry points, e.g.
FORBID_C_FUNCTION(char*, strerror, (int))
with attributes at the end or something like that.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2564692959
More information about the graal-dev
mailing list