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


Groups > comp.lang.c > #380734

Re: bart again (UCX64)

From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.lang.c
Subject Re: bart again (UCX64)
Date 2024-01-23 15:59 -0800
Organization None to speak of
Message-ID <87r0i78uu2.fsf@nosuchdomain.example.com> (permalink)
References (16 earlier) <87jzqde9hy.fsf@nosuchdomain.example.com> <86sf3pu46x.fsf@linuxsc.com> <umii50$3p6q$1@dont-email.me> <umipme$8lo2$1@dont-email.me> <86zfwvejxi.fsf@linuxsc.com>

Show all headers | View raw


Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 28.12.2023 02:14, James Kuyper wrote:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> [...]
>>>>
>>>>> You have not so far answered the question.  An answer would
>>>>> have included [...]
>>>>
>>>> I suggest you look up the word "answer" in an English
>>>> dictionary.  I did answer.
>>>
>>> I was somewhat disappointed when I did look it up.  A question is a
>>> request for information, and I had understood an answer to be a response
>>> to that question which provided the requested information.  The answer
>>> could be erroneous, or deliberately wrong or misleading, but it was not
>>> an answer unless it at least pretended to provide the requested
>>> information.  I was familiar with the common practice of saying that, for
>>> instance, "The guard asked 'Who goes there?', and the the commando
>>> answered with a knife to the guard's heart.", but I always considered
>>> that calling something like that an "answer" was a kind of joke.  I might
>>> have imagined that a dictionary would provide a more general definition
>>> of "answer" that included such things, but I expected that there would
>>> also be a more restricted definition that excluded any response that did
>>> not provide the requested information.
>>> However, that's not what I found.  For instance, Wiktionary defines an
>>> answer as "something said or done in reaction to a statement or
>>> question."  I saw similar definitions in several other online
>>> dictionaries.  Therefore, ANYTHING you do when reacting to a question
>>> qualifies as an answer, whether it be a lie, or a non-sequitur, or a
>>> blow to the head.
>>> Therefore, I reluctantly concede that you did answer the question.  You
>>> did not, however, provide the requested information.
>>>
>>> I find those definitions problematic.  If a form says "Answer the
>>> following questions", is i really instructing you to do whatever you
>>> want to do?  If so, what's the point of providing such an instruction?
>>
>> This is a nice contribution to a somewhat heated conversation.  Yes, an
>> answer without information is of little use (on the information level).
>>
>> Technically it has been answered, but arbitrary answers alone do not
>> help.  [...]
>
> I think it's worth reviewing what happened.  I should say that my
> review here is being done from memory so some of the details may
> be a little off, but the principal points should be reasonably
> accurate.
>
> Keith Thompson posted a message in the newsgroup here in a thread
> I was not involved in.  In response to his posting I posted a
> very short reply.  Keith responded to that posting asking for
> a fuller explanation of my comment.  (Let me add parenthetically
> that his action in doing that is perfectly reasonable.)

Yes.

> When I saw his response, I realized that my statement had been
> misunderstood.  I explained that, and said something to the
> effect of not wanting to try to unravel the confusion because it
> wasn't worth the trouble.  Keith responded to that posting,
> asking again for an explanation of the statement that he thought
> I made but was not what I had meant to say.

I stated that a certain program, involving a non-void function 
with no return statement and a caller attempting to use the result of a
call to that function, has undefined behavior but does not violate any
syntax rule or constraint.

Your response was "I say it does.".

> I responded again trying to explain that there had been a
> miscommunication, and (as I recall) saying again that trying to
> unravel that misunderstanding was too much trouble.  I took
> responsibility for the confusion of my original statement, and
> said "I withdraw my previous statement.  Okay?".  Keith responded
> to that posting, probably asking his same question again, however
> I don't remember any specific details.

I believed, and still do believe, that my original statement was
factually correct: the code does not violate any syntax rule or
constraint.  Your response clearly stated, incorrectly I believe, that
it does violate some syntax rule or constraint.

You're now saying that you withdrew your statement.  I absolutely did
not see anything from you indicating such a withdrawal until now.  It's
certainly possible that I missed something, but unlikely that nobody
else saw your withdrawal.  Based on what I've seen here, the only
information I had was that (a) you asserted that the code violated some
syntax rule or constraint, (b) you did not say which syntax rule or
contraint was violated, in spite of my repeated requests that you do so,
and (c) you later claimed to have answered my question.  I had no idea
why you would refuse to provide a clarification.

If you're now withdrawing your original claim, I'll accept that.  Next
time, I urge you to consider not wasting everyone's time in this manner.

> I don't remember anything else until at some later point Keith
> accused me of not having answered his question.  To be clear,
> what he was asking me was to give an explanation of a statement
> that I never made, and I had tried to explain that I never made
> it, and in any case had no interest in discussing, even assuming
> that I know what it is he meant with his question.  My impression
> is that Keith never understood that what I originally said was
> not the same as what he was asking about.

No, I was asking you to give an explanation of a statement that you very
clearly did make.  I see no reasonable interpretion other than that you
were saying that some language rule was violated.  Of course we all make
mistakes, but I was not under the impression that you had acknowledged
a mistake (and I'm not entirely sure you're doing so now).

Perhaps you meant something else by "I say it does.", but the meaning
seemed crystal clear in context, and I never saw an attempt from you to
clarify it.

> Since I tried not once but twice (or maybe a third time, I'm not
> sure) to explain that he was asking for an explanation of
> something I never said, and said in effect that the confusion was
> my fault, and explicitly withdrew my original statement, I feel
> justified in thinking that I gave a fair response to his
> inquiries.  If he's not satisfied with what I said, well, he is
> entitled to his own views.  But rather than saying something
> about himself not being satisfied, he made an accusation against
> me.  IMO the accusation made is off the mark, in both the letter
> and the spirit of the English language.  Feeling that I had been
> unfairly accused, I felt obliged to respond in an effort to
> convey that.

If I had seen your withdrawal of your original statement, this dicussion
would have been over long ago.

To be clear, do you now say that you agree that the code in question
does not violate any syntax rule or constraint?  And can you cite an
article (which I must have missed) in which you withdrew your original
"I say it does." statement?

If you can access the message with message-id <86jzt5pgho.fsf@linuxsc.com>,
posted Sep 4 2023, it contains your original statement.  See also
<https://groups.google.com/g/comp.lang.c/c/O-V_X7Cfc6I/m/gQdUwhKBAwAJ>
(scroll down, the message content should be expanded).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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


Thread

Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-25 17:45 -0800
  Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-25 21:12 -0800
  Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-12-27 20:14 -0500
    Re: bart again (UCX64) Julieta Shem <jshem@yaxenu.org> - 2023-12-27 23:22 -0300
      Re: bart again (UCX64) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 04:25 +0100
    Re: bart again (UCX64) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 04:22 +0100
      Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-23 14:58 -0800
        Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 15:59 -0800
          Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2024-01-24 10:30 +0100
            Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-24 11:57 -0500
              Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 11:26 -0800
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-14 21:14 -0800
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-14 22:29 -0800
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-19 17:53 -0800
              Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2024-01-25 09:15 +0100
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 07:16 -0800
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2024-01-26 09:20 +0100
    Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-12-28 09:12 +0100
      Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-12-28 16:31 +0800
    Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-23 15:06 -0800

csiph-web