ALLOW_C_FUNCTION's first parameter doesn't seem very helpful
Kim Barrett
kim.barrett at oracle.com
Tue Apr 4 03:02:21 UTC 2023
> On Apr 2, 2023, at 10:26 AM, Julian Waters <tanksherman27 at gmail.com> wrote:
>
> Hi everyone,
>
> I couldn't help but notice that the method name passed to the macro to allow use of itself isn't really needed in any way. Comments in the macro definition say it's to show exactly what method is being permitted by the macro, but to me it seems the actual call to it that happens in the second half of the macro already does that job entirely
>
> // It's already obvious from the actual method call itself that we want std::_Exit
> ALLOW_C_FUNCTION(::_Exit, ::_Exit(code);)
>
> Is there a reason we still keep the first parameter around other than for documentation purposes?
The using-statement is not always a simple call expression. (We have many that
aren't.) There could be some other function call that is directly providing an
argument to the function being permitted. Or the use being permitted could be
directly providing an argument to some other function. In such statements,
which function is being allowed? (I think there are currently no uses of
either of those argument passing forms. Also, restructuring such code could
probably dodge that question.)
More importantly, some implementation approaches I tried for some platforms
needed that information. I didn't get any such to work, but maybe someone more
clever will find a way.
Given that there really shouldn't be a lot of these, I'm not too worried about
making the syntax easy to use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230404/aa5edc0c/signature-0001.asc>
More information about the hotspot-dev
mailing list