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

Groups > comp.lang.c > #379504

Re: Call to a function

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

>> James Kuyper <james...@alumni.caltech.edu> writes:
>>
>>> On 2023-10-29, Tim Rentsch wrote:
>>>
>>>> James Kuyper <james...@alumni.caltech.edu> writes:
>>>>
>>>>> On 10/24/23 8:54 PM, Tim Rentsch wrote:
>
> ...
>
>>>>>> 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?
>>>
>>> As I said.  and you quoted above, "No such requirement applies to
>>> any program which is not strictly conforming".  That means that
>>> "there is no requirement to accept" or in other words "it is
>>> allowed to not accept", or in other words "it is allowed to
>>> reject".  How could I have reworded that comment to render it
>>> unnecessary for you to ask the above question,
>>
>> Give a direct answer:  "I believe the intent of the C standard
>> allows an implementation not to accept any program that is not
>> strictly conforming.  (When you say reject I'm assuming you
>> mean the opposite of accept.)" Just those two sentences, and
>> nothing more.
>
> There's several problems with that formulation, which is why I didn't
> use it:
> 1.  "I believe" implies either uncertainty, or that I consider it to be a
> matter of opinion, not a matter of fact.  Neither of those apply in this
> context.
>
> 2. "the intent of the C standard" - the C standard is a document;  it is
> the C committee which had an intent, not the standard itself - but
> that's a nitpick.
> I'm primarily interested in what the standard actually says.  I've an
> interest in what the intent was only to the extent that I believe that
> the standard fails to correctly reflect the committee's intent.  In that
> case the intent is valuable for determining how the standard needs to be
> corrected to express that intent.  I don't think that's applicable in
> this context.
>
> My statement was that, as a matter of fact, not an opinion, the C
> standard allows an implementation to not accept a program that is not
> strictly conforming, by the simple expedient of making the only
> requirement that a program be accepted dependent on it being strictly
> conforming.
>
> There is uncertainty and room for differences of opinion about the
> meaning of "accept"- but I don't see that uncertainty as being relevant
> to Keith's original question.  Unless the definition of "accept" is so
> weird that it includes rejecting the program, Keith's point stands.  As
> far as I know, no one has proposed a definition for "accept" that is
> that weird.
>
>>> and why would such re-wording have been necessary?
>>
>> First, because I wasn't sure after reading your long answer
>> whether you might have been trying to make some subtle
>> distinction between the question I asked and the answer you were
>> giving.
>
> I was, and quite explicitly so.  The key distinction is that the standard
> only talks about acceptance, while Keith's question and yours were about
> rejection.  However, unless your definition of "accept" is so weird that
> and implementation could simultaneously be said to have accepted and
> rejected a program, that clause prohibits rejecting this strictly
> conforming code.
>
>> Second, the purpose of posing the question I asked was to make
>> sure there is consensus on the threshold question. ...
>
> I don't see why - what evidence is there that anyone fails to have
> consensus on that point?  Everyone who's claimed that such code cannot be
> rejected has explicitly said that it was because they believe the code
> is strictly conforming.  No one has suggested that it fails to be
> strictly conforming, but still cannot be rejected.
>
>
>> ... I think it's
>> important to focus on this issue while it is still being debated.
>> I expect you have observed that of the four people responding, two
>> have agreed (you and Kaz) and two have not agreed (Richard Damon
>> and Keith Thompson).
>
> The situation is not as simple as agreement or disagreement.  Kaz appears
> to agree that strictly conforming code must be accepted, but expresses
> extreme agnosticism about what "accept" means, which is pretty much in
> agreement with me.  He has, however, claimed (on 2023-10-03) that the
> if(0) guaranteeing that the code does not get executed does not protect
> the code from having undefined behavior, whereas I read the resolution
> of DR 109 as indicating that it does protect it - the code mentioned in
> DR 109 was far less well protected against execution than this code, and
> was still strictly conforming.
>
> Richard Damon claimed that rejecting a program requires a constraint
> violation, which is incomplete.  A program may also be rejected for a
> syntax error or for having code that would have undefined behavior if
> executed, if that it was guaranteed that the code would be executed if
> the program were executed.  DR 109 made it clear that unless the code is
> guaranteed to be executed, the fact that it would have undefined
> behavior if executed does not, in itself, allow rejection of the
> program.  Since his contribution was rather brief, and no one mentioned
> those points in response to that message, I'm not sure whether leaving
> those exceptions out was accidental.
>
> Keith has some subtle disagreements with me about the meaning of the
> word "accept" - I say it's unspecified, so the requirement could be met
> just by issuing a message "Program Accepted" - he thinks the meaning is
> unclear, but is intended to be much stronger than that.  However, he
> agrees with me that this code is strictly conforming, and that, as a
> result, an implementation is not permitted to reject it.
>
> I posted a followup question in response to
>
>> Richard's answer, but he has not yet replied.  Keith's comments
>> have been the most emphatic in disagreeing, and I think it would
>> help to discuss the threshold question separately before we get to
>> the larger question, so the discussion doesn't get too confused.
>
> Keith is the one who has, most emphatically, asserted that the reason it
> cannot be rejected is because it is strictly conforming - how could your
> "threshold question" come into play?
>
>>> The key point is that the code in question is strictly conforming,
>>> and a implementation therefore IS required to accept it.
>>
>> Before I explain why that isn't so I really think it would help to
>> make sure everyone is on the same page with respect to the threshold
>> question, because if someone doesn't agree that the standard allows
>> a conforming implementation to reject any program that isn't
>> strictly conforming there is no point trying to explain to them
>> further.
>
> But no one has said anything to justify having any doubts about whether
> they would agree.  It is the strict conformance of the code that they are
> asserting, not a requirement to accept code that isn't strictly conforming.
>
>>> You earlier claimed "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."
>>> Since ensuring that such code might not get executed is sufficient
>>> to make the program strictly conforming (DR 109), and this code
>>> guarantees that it won't be executed, how can an implementation be
>>> within it's rights to reject it?
>>
>> Your reasoning is fine as far as it goes, but it's incomplete.  I
>> still would like to reach a shared understanding about the threshold
>> question.  I just posted a reply earlier today to two of Keith's
>> postings on this, let's give him a chance to respond before going
>> further.
>
> His last message that I've seen indicates that he will not respond until
> you answer his question: ""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?"
>
> If you also refuse to answer his question until he answers yours, the
> two of you are at an impasse.  I consider his insistence on an answer to
> be more reasonable than yours, because it is the directly relevant
> question.  I consider your insistence to be unreasonable, because nobody
> has said anything to suggest disagreement with your threshold question.
> In fact, we've tried (and apparently, in your eyes, failed, for reasons
> that are unclear) to express basic agreement with it (subject to minor
> quibble about the relationship between "accept" and "reject").  We only
> disagree about it's applicability to this strictly conforming code.

I don't see what it is you are hoping to accomplish with the
above comments.  Can you shed some light on that?

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

Thread

Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-10 12:08 -0500
  Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-13 08:16 -0800
  Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-13 14:15 -0500
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-14 09:02 -0800
    Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-14 13:10 -0500
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-18 23:27 -0800
    Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-19 12:22 -0500
      Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-19 13:31 -0800
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 18:15 -0800

csiph-web