Poisoning in HotSpot

[Kim Barrett]

On 11/26/24 11:54 PM, Julian Waters wrote:
> Hi Kim,
>
> Darn, that's unfortunate. There was an earlier prototype I had that
> does solve this issue, but unfortunately the error message resulting
> from someone trying to use a poisoned method is much less clear in
> that one:
>
> [... snip ...]
>
> Will get the following compile error:
>
> <source>: In function 'int main()':
> <source>:20:25: error: call of overloaded 'malloc(size_t)' is ambiguous
>     20 |     void *ptr = ::malloc(size_t{1});
>          |
> In file included from
> /opt/compiler-explorer/gcc-trunk-20241126/include/c++/15.0.0/cstdlib:83,
>                   from <source>:2:
> /usr/include/stdlib.h:540:14: note: candidate: 'void* malloc(size_t)'
>    540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__
>           |              ^~~~~~
> <source>:17:25: note: candidate: 'void* {anonymous}::malloc(size_t)' (deleted)
>     17 | FORBID_C_FUNCTION(void *malloc(size_t size), "use os::malloc",
> return ::malloc(size);)
>          |                         ^~~~~~
> <source>:12:33: note: in definition of macro 'FORBID_C_FUNCTION'
>     12 |     [[deprecated(alternative)]] signature noexcept = delete;           \
>          |                                 ^~~~~~~~~
>
> Unless ::malloc is wrapped in ALLOW_C_FUNCTION

Yeah, the error message for that isn't all that nice. Though it's
not *completely* terrible. The relevant information is all there. It's just
somewhat buried in a bunch of not relevant stuff. I wonder what other
compilers give.

Also, using anonymous namespaces in headers is kind of fraught, as it can
easily result in ODR violations. Though maybe the always_inline might be
sufficient to dodge that here.  But I wonder if the namespace needs to be
anonymous, since it's being declared inline.  Maybe give it a descriptive
name, like `forbidden_c_functions`.

> As for the scoped attributes, for this particular case HotSpot has the
> ALWAYSINLINE macro, which bypasses the issue of having unknown
> attributes. They could be defined to the corresponding scoped
> forceinline attribute that the compiler understands, which avoids
> compile failures

We don't need to mess with scoped attributes here. As you mentioned, we *do*
have ALWAYSINLINE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241129/a09f32da/attachment-0001.htm>