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

Groups > comp.lang.c > #379356 > unrolled thread

Re: Call to a function

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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 James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-19 18:50 -0500

#379356 — Re: Call to a function

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?

[toc] | [next] | [standalone]

#379399

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

[toc] | [prev] | [next] | [standalone]

#379497

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> 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?
>>>
>>> [...]

Let me respond now to the paragraph below, and get back to your
other comments in a later posting.

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

To be clear, my question above is meant to elicit your views on
what I asked about.  My question was not meant to educate you, to
be a Socratic question, or to steer you in any particular
direction.  I was only looking for an answer, nothing more.

I ask the question because it is a threshold question for your
earlier question upthread.  My answer to your prior question
depends on this premise for its conclusion.  I asked my question
separately because I want to clarify the discussion.  As things
stand, my question has gotten a yes answer from James Kuyper and
Kaz, and a no answer from Richard Damon and yourself.  I
responded to Richard's posting sometime last week but have not
seen any followup from him on that.  I responded to several of
your postings just in the last day, so I'm not sure if you have
had a chance yet to read those.  If after reading my comments you
agree that the C standard allows implementations not to accept
any program that is not strictly conforming then I can go ahead
and answer your question.  If after reading my comments you still
do not agree to that premise then there really isn't anything
more for me to say other than I believe your understanding of the
C standard is not consistent with what its authors intend.  I can
agree to accept (no pun intended) either view as your final
opinion on the matter.

[toc] | [prev] | [next] | [standalone]

#379513

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

> (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.  [...])

I don't remember any outstanding question from the discussion of
falling off the end of a non-void function.  Looking back over
postings from you responding to a posting of mine I don't see
any either.  I guess it's possible there was a question but I
didn't see it.  In any case I have no idea what question in that
thread you want answered, so if you still want an answer please
ask the question again.

[toc] | [prev] | [next] | [standalone]

#379517

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.

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

It is the pointer conversion expression that makes the program be
not strictly conforming.

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

I'm not.

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

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

[toc] | [prev] | [next] | [standalone]

#379525

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

[toc] | [prev] | [next] | [standalone]

#379528

> Keith Thompson <Keith.S.T...@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.

The committee has officially ruled in DR 109 that code with undefined
behavior renders the program not strictly conforming, only if execution
of that code is an inevitable consequence of running the program. Not
only is execution of this code not inevitable, it is in fact impossible
for it to be executed.

I'm curious - on what platform is it impossible, or at least difficult,
to translate an if(0) block as a no-op? I'd think that simply failing to
generate any corresponding machine code would be sufficient on most, if
not all, platforms.

The code that appeared in DR 109 was not a no-op, but the behavior of
any program that called the function would be undefined, which means
that the standard imposes no requirements on its behavior. On what
platform is it difficult to generate code that has no requirements on
how it behaves? I'd think it would be trivial translate it as, for
instance, the equivalent of

fprintf(stderr, "ISO C does not define the behavior of converting \n"
    "a pointer to an object into a pointer to a function.\n");
exit(EXIT_FAILURE);

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web