Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #379525

Re: Call to a function

Show all headers | View raw

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> The code we're discussing was snipped at some point, so here it
>> is again:
>>
>> int main(void) {
>>     int obj = 42;
>>     typedef void func(void);
>>     if (0) {
>>         func *fptr = (func*)&obj;
>>         fptr();
>>     }
>> }
>>
>> It illustrates the issue that the standard does not define the behavior
>> of a conversion from an object pointer type to a function pointer type
>> (other than the special case of a null pointer constant), but does not
>> make such conversion, expressed as a cast, a constraint violation.
>>
>> I asked:  "On what basis do you think a conforming implementation may
>> reject it?
>
> The code is not strictly conforming.
>
>> Do you see a syntax rule or constraint that it violates?
>
> No.
>
>> Do you see some other basis for rejecting it?"
>
> Yes.  The conversion expression can be untranslatable on some
> platforms.  That means any such expression cannot be part of
> a strictly conforming program.

I disagree.  A conforming implementation could implement a conversion of
an object pointer to a function pointer that always yields a null
pointer, or that yields a pointer whose representation is derived from
the representation of the operand.  The latter is typically done for
pointer-to-integer or integer-to-pointer conversions with mismatched
sizes (6.3.2.3 explicitly says that integers may be converted to
pointers and vice versa).

If, hypothetically, the standard said that an otherwise valid program
containing a conversion of an object pointer to a function pointer type
must be successfully translated, then compiler implementers could easily
find a way to implement such conversions, even if the result is not
useful.  It is incorrect to claim that such a conversion expression may
be "untranslatable".

[...]

> I have no interest in treating you as a student.  I'd be much
> happier if you would do more thinking for yourself.

I would be happier if you would not assume that I'm not already
doing that.  Be less arrogant.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

Thread

Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-29 05:47 -0700
  Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-29 14:40 -0700
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-10 06:33 -0800
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-17 21:16 -0800
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-19 00:09 -0800
      Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-19 13:20 -0800
        Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-19 12:49 -0800
          Re: Call to a function Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 03:27 +0000
            Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-21 20:14 -0800
            Re: Call to a function scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 16:36 +0000
              Re: Call to a function Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 22:05 +0000
    Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-19 18:50 -0500
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 18:11 -0800
      Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 14:19 -0500

csiph-web