RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris
kim.barrett at oracle.com
Wed Mar 23 01:43:02 UTC 2016
> On Mar 22, 2016, at 12:13 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 22/03/2016 1:21 PM, Kim Barrett wrote:
>> Note, however, that the POSIX description of dlsym says (in the non-normative “Application Usage” section):
>> Note that conversion from a void * pointer to a function pointer as in:
>> fptr = (int (*)(int))dlsym(handle, "my_function");
>> is not defined by the ISO C standard. This standard requires this conversion to work correctly on conforming implementations.
>> I only noticed this today. So maybe CAST_TO_FN_PTR is not needed in Unix/POSIX-specific code?
> You pre-empted my next question: given dlsym returns void* and has to be converted to a function ptr there would have to be some legal way to achieve this. :) Kind of interesting though that POSIX puts an obligation on the compiler writer.
> Looking at the C standard, given any function-ptr can be converted to another type of function-ptr and back without change, it seems to me that the return type of dlsym (and related library calls) should be void(*)(void) to be strictly correct wrt the language standards.
That wouldn’t work. Not everything dlsym returns is a function pointer; it can also return pointers to variables.
> But in practice as long as pointers are all the same size (which seems the obvious and common implementation [ but by no means guaranteed ]) then the conversion works correctly with no actual changes to the bits.
It’s been a really long time, but I think some MS-DOS data models had the property that function pointers and data pointers had different sizes. Ah, internet to the rescue:
- medium. Near addresses are used for data but far addresses are used for code. This restricts the data space to 64 KByte and the code space to 256 MByte. This suggests a large complex program manipulating a small amount of data.
- compact. Far addresses are used for data but near addresses are used for code. This restricts the data space to 256 MByte and the code space to 64 KByte. This suggests a small simple program manipulating a massive amount of data.
Note: 256 MBytes == "massive amount of data" :-)
> Just for fun I'll do a JPRT run to see if anything complains if CAST_TO_FN_PTR(type,val) simply does ((type)(val)).
Which I see worked. Starter bug?
Oh, but did you try
#define CAST_TO_FN_PTR(type, val) reinterpret_cast<type>(val)
I found some discussions that suggest some C++ compilers allow void* -> function pointer conversion with a C-style cast and disallow with a reinterpret_cast. In other words, in some implementations there is a conversion that can *only* be done with a C-style cast, not with any C++ cast operator. Feh!
Oh, and in case you are interested, here’s the C++ committee discussion:
So the reinterpret_cast is conditionally supported in C++11.
And I think that’s far enough down this rabbit hole for me.
More information about the hotspot-runtime-dev