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

[Kim Barrett]

> On Mar 21, 2016, at 8:00 PM, David Holmes <david.holmes at oracle.com> wrote:
>> 
>> reinterpret_cast (and all the C-style casts involved are really
>> reinterpret_casts) can be used to convert a function pointer to a
>> different function pointer type.  It can also be used to convert
>> between any pointer (including function pointers) and (appropriate)
>> integer types.  No other conversions involving function pointers are
>> allowed.  (C++11 adds "Converting a function pointer to an object
>> pointer type or vice versa is conditionally-supported.")
>> 
>> Since void* is not a function pointer type, there's no specified
>> direct conversion from a void* to a function pointer.  That's the
>> raison d'etre for CAST_TO_FN_PTR. (Although conversion to an integer
>> then to some other type (not back to the original type) and then use
>> is implementation-defined.)
>> 
>> However, it seems that some compilers (including the Solaris versions
>> we've been using) allow direct void* -> function pointer conversions.
> 
> I thought any pointer type could be converted to void* and back again?

Only for object pointers, not for function pointers.

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?

Unfortunately, the description of CAST_TO_FN_PTR is kind of vague, so it’s unclear who the culprit(s) that led to it might be.  It would be easy enough to simplify the macro definition and see if any currently supported compilers complain.  And there are only 136 occurrences to clean up if that becomes a thing to do.