Re: Casting the return value of ...

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c
Subject	Re: Casting the return value of ...
Date	2024-03-30 02:32 -0700
Organization	A noiseless patient Spider
Message-ID	<86plvchxpn.fsf@linuxsc.com> (permalink)
References	(1 earlier) <20240328105203.773@kylheku.com> <87frwatadu.fsf@nosuchdomain.example.com> <uu4k1c$3pq71$1@dont-email.me> <uu6dtk$a076$1@dont-email.me> <uu6fss$agvi$1@dont-email.me>

Show all headers | View raw

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.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Casting the return value of ... gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-28 15:09 +0000
  Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 18:16 +0000
    Re: Casting the return value of ... scott@slp53.sl.home (Scott Lurndal) - 2024-03-28 18:53 +0000
      Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-30 10:33 -0700
        Re: Casting the return value of ... scott@slp53.sl.home (Scott Lurndal) - 2024-03-30 19:29 +0000
          Re: Casting the return value of ... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-30 23:05 +0000
            Re: Casting the return value of ... scott@slp53.sl.home (Scott Lurndal) - 2024-03-30 23:25 +0000
            Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-31 15:44 +0200
            Re: Casting the return value of ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-31 13:15 -0700
          Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-08 23:01 -0700
            Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-04-09 10:03 +0200
    Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 12:38 -0700
      Re: Casting the return value of ... bart <bc@freeuk.com> - 2024-03-28 20:30 +0000
        Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 14:07 -0700
          Re: Casting the return value of ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-28 14:15 -0700
          Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 21:44 +0000
            Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 22:01 +0000
              Re: Casting the return value of ... Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-28 22:33 +0000
                Re: Casting the return value of ... Michael S <already5chosen@yahoo.com> - 2024-03-29 15:53 +0200
                gcc Bugzilla search (was: Casting the return value of ...) Michael S <already5chosen@yahoo.com> - 2024-03-29 16:01 +0200
                Re: gcc Bugzilla search David Brown <david.brown@hesbynett.no> - 2024-03-29 17:00 +0100
            Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 15:37 -0700
          Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-29 14:06 +0100
            Re: Casting the return value of ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-29 15:46 -0700
        Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-29 13:58 +0100
          Re: Casting the return value of ... bart <bc@freeuk.com> - 2024-03-29 13:32 +0000
            Re: Casting the return value of ... David Brown <david.brown@hesbynett.no> - 2024-03-29 17:10 +0100
            Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-30 02:32 -0700
              Re: Casting the return value of ... bart <bc@freeuk.com> - 2024-03-30 11:14 +0000
                Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-08 23:41 -0700
  Re: Casting the return value of ... Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-03-28 21:41 -0700
    Re: Casting the return value of ... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-28 22:02 -0700
  Re: Casting the return value of ... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-29 15:52 -0700

csiph-web