RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris

[Kim Barrett]

> 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:

http://www.scit.wlv.ac.uk/~in8297/CP4044/cbook/chap6/chap6.msdos.memory.html

- 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:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#195
So the reinterpret_cast is conditionally supported in C++11.

And I think that’s far enough down this rabbit hole for me.