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


Groups > comp.lang.c > #379497

Re: Call to a function

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.lang.c
Subject Re: Call to a function
Date 2023-11-10 06:33 -0800
Organization A noiseless patient Spider
Message-ID <86edgxznhy.fsf@linuxsc.com> (permalink)
References (4 earlier) <87h6n7tkv4.fsf@nosuchdomain.example.com> <86ttqf2w6p.fsf@linuxsc.com> <uha85r$ha56$1@dont-email.me> <86msw11tpp.fsf@linuxsc.com> <87leblhzud.fsf@nosuchdomain.example.com>

Show all headers | View raw


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.

Back to comp.lang.c | Previous | NextPrevious 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