Re: Casting the return value of ...

bart <bc@freeuk.com> writes:

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.

There is not, if it's important that it work reliably across
different compilers and different platforms.

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.

Function pointers and object pointers don't have to be the same
size, or use the same form of representation.  The C standard
allows implementations where code and data live in completely
separate memories.  In such cases there is no sensible way to
convert between the two kinds of pointers, because the two kinds
of addresses have no relationship to each other.

Yet converting either to and from an integer type is perfectly
fine, even though it isn't even a pointer type!

Converting to an integer type might be okay but it doesn't have
to be.  The C standard says this explicitly:

  Any pointer type may be converted to an integer type.  Except
  as previously specified, the result is implementation-defined.
  If the result cannot be represented in the integer type, the
  behavior is undefined.  The result need not be in the range of
  values of any integer type.

Note in particular the last sentence.

I wonder then why a conversion between function and object
couldn't be implemented, internally, via such an intermediate
integer type anyway.

On platforms where object pointers and function pointers both
point into the same address space, converting between the two
kinds of pointers could be implemented internally just by
copying the bits, without having to go through some integer
intermediate.  Indeed I expect that implementations that
support the extension of converting between the two kinds
of pointers do just that.  But there is no guarantee this
kind of approach will work on other platforms.  Because the
C standard is meant to apply to platforms where function
pointers and object pointers have no relationship to each
other, the C standard does not give permission to convert
between them.