Poisoning in HotSpot

[Julian Waters]

VC returns:

<source>(21): error C2668: 'malloc': ambiguous call to overloaded function
Z:/compilers/windows-kits-10/include/10.0.22621.0/ucrt\corecrt_malloc.h(101):
note: could be 'void *malloc(size_t)'
<source>(18): note: or       'void *forbidden::malloc(size_t) noexcept'
<source>(21): note: while trying to match the argument list '(size_t)'
Compiler returned: 2

While clang returns:


<source>:21:17: error: call to 'malloc' is ambiguous
   21 |     void *ptr = malloc(size_t{1});
      |                 ^~~~~~
/usr/include/stdlib.h:540:14: note: candidate function
  540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__
      |              ^
<source>:18:25: note: candidate function has been explicitly deleted
   18 | FORBID_C_FUNCTION(void *malloc(size_t), "use os::malloc")
      |                         ^
1 error generated.
Compiler returned: 1

https://godbolt.org/z/zbfPzoz54

I managed to put in an override system to allow C Standard library
methods to be used when they are really needed, but unfortunately the
method body of the forwarding method that calls the actual C library
code is still defined in a rather clunky way

best regards,
Julian


On Sat, Nov 30, 2024 at 3:43 AM Kim Barrett <kim.barrett at oracle.com> wrote:
>
> 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.