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

Groups > comp.lang.c > #379399

Re: Call to a function

Show all headers | View raw

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>> The point isn't quite the same.  The C standard explicitly says
>>>>> integers may be converted to any pointer type.  The C standard
>>>>> does not say that a pointer to an object type may be converted
>>>>> to a pointer to function type.  Every implementation is within
>>>>> its rights to reject any program whose static text includes[*] a
>>>>> cast from a pointer to an object type to a pointer to function
>>>>> type, regardless of whether the cast has any chance of being
>>>>> executed.
>>>>>
>>>>> [*] meaning, still present as source of any preprocessor
>>>>> conditionals have been processed, etc.
>>>>
>>>> I disagree.  (I think we've discussed this before.)
>>>>
>>>> Concretely, I believe that this program violates no syntax error
>>>> or constraint.  It includes code whose behavior would be undefined
>>>> if it were executed, but the `if (0)` prevents that.
>>>>
>>>> On what basis do you think a conforming implementation may reject
>>>> it?
>>>
>>> First let me ask a question.  Does the C standard allow an
>>> implementation to reject any program that is not strictly
>>> conforming?
>>
>> [...]
>>
>> The standard never talks about rejection.  It requires that "A
>> conforming hosted implementation shall accept any strictly
>> conforming program.".  No such requirement applies to any program
>> which is not strictly conforming.  (4p6)
>
> Perhaps I shouldn't have used the word "reject".  If the question
> were phrased "Does the C standard allow an implementation not to
> accept any program that is not strictly conforming?", does your
> comment above mean you would say Yes to that question?

I've decided not to answer any more of your questions until you
answer mine.

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?  Do you see a syntax rule or constraint that it violates?  Do
you see some other basis for rejecting it?"

To be clear, I'm asking about whether an implementation may reject it
specifically because of the pointer conversion, not about reasons for
rejecting it that would apply equally to a "hello, world" program.

Feel free to disregard the following paragraphs.

The impression I get (very likely a wrong one) is that you are
trying to use a Socratic method, asking me questions that you
think will steer me to the correct conclusion -- a conclusion that
you have not shared.  I am not speculating about your motivations
(which you hide very well); rather, I am letting you know about the
impression that I get from what you write.  I'm interested in what
you think about relevant technical issues, but I'm not interested
in playing the role of your student.

(We have two similar discussions happening in parallel in different
threads.  The other one involved a non-void function falling off
the end, with the caller attempting to use the result.  I won't get
into that code in this thread, other than to say that I'm awaiting
your answer there as well.  In both threads, it's becoming difficult
to remember what was being discussed in the first place.)

-- 
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