Re: Casting the return value of ...

On 29/03/2024 12:58, David Brown wrote:

On 28/03/2024 21:30, bart wrote:

On 28/03/2024 19:38, Keith Thompson wrote:

Kaz Kylheku <433-929-6894@kylheku.com> writes:
[...]

Conversions between function pointers and data pointers are an
extension; it is not well-defined behavior in ISO C.
>
Therefore we can neither say that ISO C doesn't require a cast there (it
imposes no requirements at all), nor that the conversion is fine with a
cast.
>
The cast is /likely/ necessary, in order to correctly trigger the
extension.

>
ISO C does require a cast.  The cast is necessary to avoid a constraint
violation and a mandatory diagnostic.  The resulting behavior is
undefined in ISO C, but defined by POSIX.
>
Assigning a void* value to a pointer-to-function object without a cast
violates the constraint for simple assignment (N1570 6.5.16.1p1).

>
What would such a cast look like? Since this gives a warning with -Wpedantic even with a cast:
>
     void* p;
     void(*q)(void);
>
     p=(void*)q;
     q=(void(*)(void))p;
>
>

 One method that silences all gcc warnings here is to cast via uintptr_t:
 #include <stdint.h>
 void* p;
void(*q)(void);
 typedef void(*FVoid)(void);
 void foo(void) {
     p = (void*) (uintptr_t) q;
}
 void bar(void) {
     q = (FVoid) (uintptr_t) p;
}

I was aware of the double conversion but KT used 'a cast' so I wondered if there was a single cast that could be used.
It is odd however that function and object pointers can be considered so different that even an explicit conversion between them is deemed to be meaningless.
Yet converting either to and from an integer type is perfectly fine, even though it isn't even a pointer type!
I wonder then why a conversion between function and object couldn't be implemented, internally, via such an intermediate integer type anyway.