On 9/5/23 02:49, Kaz Kylheku wrote:
> On 2023-09-05, vallor <vallor@cultnix.org> wrote:
....
>> Isn't asking a C compiler to watch for interminable loops and
>> such things akin to trying to solve the halting problem?
>
> The Halting Problem is academic. The main reasons why you can't
> accurately determine reachability in C programs are practical:

If the C standard mandated diagnosing unreachable code, that would
require solving the Halting Problem, which is impossible. Because the C
standard does not mandate diagnosing unreachable code, and allows
implementations to issue arbitrary diagnostics for any reason they wish,
an implementation of C is free to diagnose the easy cases, while leaving
harder cases undiagnosed.
That's why it's important to be aware of the Halting Problem, despite it
being of mostly academic interest.

On 2023-09-09, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 9/5/23 02:49, Kaz Kylheku wrote:
>> On 2023-09-05, vallor <vallor@cultnix.org> wrote:
> ...
>>> Isn't asking a C compiler to watch for interminable loops and
>>> such things akin to trying to solve the halting problem?
>>
>> The Halting Problem is academic. The main reasons why you can't
>> accurately determine reachability in C programs are practical:
>
> If the C standard mandated diagnosing unreachable code, that would
> require solving the Halting Problem, which is impossible.

If the C standard mandated diagnosing unreachable code, it would
require a crystal ball, which makes Turing-related difficulties
moot ... being the point.

Therefore, nobody in their right mind will do that; they will focus on
that which can be done in a way that is practical and useful, reasonably
easy to understand (and thus predict) and of the most benefit and least
nuisance.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 09/09/2023 02:47, Kaz Kylheku wrote:
> On 2023-09-08, David Brown <david.brown@hesbynett.no> wrote:
>> On 08/09/2023 11:51, Bart wrote:
>>> The internal details don't matter to the user. The way main() is defined
>>> and used should be identical to any other function.
>>
>> I too would prefer consistency here - I see no reason why falling off
>> the end of main() should act as "return 0;", except to standardise
>> existing old practice.
>
> I don't believe there was an old practice.
>
> The practice was one of hordes of programmers being ignorant of the
> concept of a termination status.
>

OK - so it was standardising practice by new, ignorant programmers.
That sounds entirely plausible to me.

> This was done in C because C++ did it.

I know C++ standardised it first.

>
> C++ did it probably because they thought it's one more way to improve
> the C subset of C++ to make a better C.
>
> By adopting such a rule at the language level, you can fix countless
> broken programs that return a pseudo-random termination status;
> they just have to be recompiled with an implementation that has picked
> up the rule.
>

Fair enough.

> I think that if C and C++ hadn't adopted this rule, we would still have
> many programs out there returning garbage termination status.
>
> Still, it's strange because C and C++ languages are not normally of the
> kind that try to save the end user from programmer ignorance. In the
> big picture, in which so many things can go wrong in developing a
> complex application, fixing the broken return of main is a like fart in
> a hurricane.
>
> ---
>
> main is not such a different function in C. It can be a perfectly
> ordinary function. What is special about it is that it can have one
> of two standard type signatures.

There are a few other differences, though main() in C is not as special
as main() in C++.

>
> However, that can be handled transparently in many implementations,
> because it is commonly de facto safe to pass more arguments to a
> function than it takes.

Yes.

>
> The ISO C <stdarg.h> feature came from something called <varargs.h>
> which was entirely predicated on passing a variable number of
> arguements to a function, prior to the existence of prototype
> declarations and the ... ellipsis.
>
> SowWhen it comes to C, main can be just an external function which is
> linked to by the "CRT" module by name, and that module can assume that
> it is int main(int, char **). (Except on implementations which have
> calling conventions whereby the callee cleans up the stack and such.)
>
> It is rather in C++ that main is more special. C++ has type safe
> linkage, and so int main(void) looks different from int main(int, char
> **). In actual implementations, this is done by encoding the type into
> the symbol name, which is informally called "name mangling".
>
> C++ implementations likely disable name mangling for main so
> that it is more easy to link to.

Indeed they do. In effect, "main" is declared as though it were an
extern "C" function, so that it is accessible from the C++ startup code.
(But you are not allowed to declare it yourself in any way.)

>
> In C++, main is not required to be recursively invokable;

You are not allowed to call it at all, or even take its address - so no
recursion is allowed.

> and it is
> probably for that reason. The definition of main is also a declaration.
> But since main is specially handled, that declaration may not actually
> be suitable for calling it. That is to say, if the C++ program calls
> main, that might generate a reference to the mangled name which doesn't
> actually exists.
>

Some C++ compilers call global constructors and static initialisation
functions from library code before main() is started. Others inject
that code into the generation of the main() function, as though it
appeared immediately after the opening braces of main(). That would not
be an option if main() could be called recursively. (Global destructors
can similarly be injected into the end of main()).

> Perhaps since C++ main is already special, it was an easier decision
> in C++ to put in the rule regarding the implicit return.
>

Certainly it made some things easier, and it definitely made the choice
of default return value easy to pick!

On 09/09/2023 03:07, Kaz Kylheku wrote:
> On 2023-09-08, candycanearter07 <no@thanks.net> wrote:
>> The magic of standards is that you don't need to worry about the
>> underlying os messiness. With that said, I didn't know about the
>> arguments issue, that's neat.
>
> Congratulation on your correct attribution and quoting via T-bird.
>
> That's pretty much a Usenet first. In my memory, nobody who has ever
> been told about things like this in any newsgroup I've ever read has
> ever done anything to alter their behavior or software configuration.
>

It's not a first - but it is definitely rare, and is, I think, the
speediest case I have seen. Welcome to the group, Candy!

On 9/9/23 9:49 AM, David Brown wrote:
> Some C++ compilers call global constructors and static initialisation
> functions from library code before main() is started.  Others inject
> that code into the generation of the main() function, as though it
> appeared immediately after the opening braces of main().  That would not
> be an option if main() could be called recursively.  (Global destructors
> can similarly be injected into the end of main()).

This was how it HAD to be done in CFront, that took C++ code and
generated C code from it, to be given to the C compiler to be compiled
and run.

CFront couldn't (portably) change the pre-main behavior, so injected it
in the front of main.

On 09/09/2023 19:27, Richard Damon wrote:
> On 9/9/23 9:49 AM, David Brown wrote:
>> Some C++ compilers call global constructors and static initialisation
>> functions from library code before main() is started.  Others inject
>> that code into the generation of the main() function, as though it
>> appeared immediately after the opening braces of main().  That would
>> not be an option if main() could be called recursively.  (Global
>> destructors can similarly be injected into the end of main()).
>
> This was how it HAD to be done in CFront, that took C++ code and
> generated C code from it, to be given to the C compiler to be compiled
> and run.
>
> CFront couldn't (portably) change the pre-main behavior, so injected it
> in the front of main.

Sounds reasonable.

I have seen it done in other C++ compilers that did not use CFront,
though I can't remember off-hand which compiler it was (it was some
microcontroller compiler).

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> This text:
>
> int main(void) { int a[] = {1}; return a[2]; }
>
> is meaningless (as C). It does not "do" anything because it
> means nothing.

I would like to offer a different perspective on this question.

I take the meaning of a C program to be a mapping from inputs
to outcomes. The term outcome is meant to be "the result" of
giving a particular input to a program, without being too
specific about what counts as part of a result. For example,
"outcome" includes the observable behavior of a program, but it
also includes exit status, which is not part of the observable
behavior. (I needed to check the definition of observable
behavior to verify that.)

The first point is that outcome is multi-valued: a result might
be a single outcome, or it might be a set of possible outcomes.
A program that relies on unspecified behavior can produce
different results depending on what choices are made in each case
where the program depends on unspecified behavior. (Side point:
I think we can treat implementation-defined behavior as simply
one more component of program input. In any case we will not
consider it further, as it shouldn't cause any serious problems.)

Viewed from this perspective, the meaning of the program above
is a set containing all possible outcomes (and incidentally that
is the result for all inputs). Of course it can be the case that
some programs have infinite outcome sets for some inputs and
finite outcome sets for other inputs. It may be surprising but
there is actually some positive information content in saying the
meaning of a program is a set of all possible outcomes. To see
that, consider this program:

int main(void) { return 1; };

No doubt there are different points of view about what the outcome
set of this program should be, but we can be sure of one thing: if
there are any elements in this program's outcome set, every one
includes at least one diagnostic message, caused by the syntax
error. So even if the outcome set is infinite, it is a proper
subset of the outcome set of the previous program with undefined
behavior (and no syntax errors or constraint violations), because
some of those outcomes do not include any diagnostics.

My inclination here is to say the second program is "meaningless"
whereas the first program does have a "meaning", even if not an
especially useful one. That view seems consistent with what is
said in the ISO C standard, the very first sentence of which
reads

This International Standard specifies the form and
establishes the interpretation of programs expressed
in the programming language C.

The "meaning" of a proprosed program text is what interpretation is
specified for it. The second program doesn't satisfy the form of
programs written in C, and hence does not have an interpretation
specified for it: meaningless. The first program does satisfy the
form of programs written in C, and so does have an interpretation
specified for it, even though what is specified is unboundedly
liberal. Furthermore I think the distinction described corresponds
to how we normally think of the words used. The second program is
"meaningless" no matter what input it is given. But it's fairly
easy to construct programs that have undefined behavior only on
very large inputs (over, say, 2**128 characters). It seems wrong
to call a program "meaningless" if its behavior is well-defined for
all inputs it will ever be run on. It's much nicer to say that such
a program is meaningful, with the outcome sets for some inputs being
infinite.

So for what it's worth, there is another taken on the matter.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 04/09/2023 12:06, Bart wrote:
>>>
>>> [...]
>>>
>>>>> char* fred(void) {
>>>>> (long long int)rand()*3.14159;
>>>>> }
>>>>> int main(void) {
>>>>> printf("%s\n", fred());
>>>>> }
>>>
>>> [...]
>>>
>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>> will - at least - warn you about it when asked to treat the input
>>>> according to the C standards. As you know, there isn't a compiler in
>>>> the world for any language which will stop programmers from writing
>>>> incorrect code.
>>>
>>> Given the context of the discussion, pedantry seems appropriate.
>>>
>>> It's invalid C code because it doesn't declare rand() and printf(),
>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>> Usenet formatting issue.)
>>>
>>> Other than that, a conforming C compiler is not required to diagnose
>>> the above code. It does have undefined behavior, and a C compiler is
>>> likely to warn about it with appropriate warnings, but it does not
>>> violate any syntax rule or constraint.
>>
>> I say it does.
>
> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
> compile the above code (once the required #include directives are added)
> without error, though clang prints a couple of optional warnings. I used
> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
> prints warnings similar to the ones clang prints without it.)
>
> What syntax rule or constraint does it violate?

I'm sorry the point I was trying to make got lost. I was
hoping for some value to result from my comment, and I feel
bad that that is unlikely to happen. I'll try to do better
next time.

> Does it occur to you that you would save everyone a lot of time if
> you'd explain what you mean in the first place?

You say that like you think saving people time should always
be my highest priority. It isn't, at least not always.
When there is some tension between two or more areas of
consideration usually (at least) one has to be shortchanged.
I prioritize the factors I think are the most important in
each particular case. I'm sorry if my choices seem poor to
you but I need to follow the path that I think has the best
chance of success.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 04/09/2023 12:06, Bart wrote:
>>>> [...]
>>>>
>>>>>> char* fred(void) {
>>>>>> (long long int)rand()*3.14159;
>>>>>> }
>>>>>> int main(void) {
>>>>>> printf("%s\n", fred());
>>>>>> }
>>>>
>>>> [...]
>>>>
>>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>>> will - at least - warn you about it when asked to treat the input
>>>>> according to the C standards. As you know, there isn't a compiler in
>>>>> the world for any language which will stop programmers from writing
>>>>> incorrect code.
>>>>
>>>> Given the context of the discussion, pedantry seems appropriate.
>>>>
>>>> It's invalid C code because it doesn't declare rand() and printf(),
>>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>>> Usenet formatting issue.)
>>>>
>>>> Other than that, a conforming C compiler is not required to diagnose
>>>> the above code. It does have undefined behavior, and a C compiler is
>>>> likely to warn about it with appropriate warnings, but it does not
>>>> violate any syntax rule or constraint.
>>>
>>> I say it does.
>>
>> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
>> compile the above code (once the required #include directives are added)
>> without error, though clang prints a couple of optional warnings. I used
>> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
>> prints warnings similar to the ones clang prints without it.)
>>
>> What syntax rule or constraint does it violate?
>
> I'm sorry the point I was trying to make got lost. I was
> hoping for some value to result from my comment, and I feel
> bad that that is unlikely to happen. I'll try to do better
> next time.

I'm sorry you chose not to answer my simple and direct question.

What syntax rule or constraint does the code violate?

Also, what was the point you were trying to make?

I asserted that the code (after adding the required #include
directives) does not violate any syntax rule or constraint.
You asserted that it does, but didn't elaborate. I asked you
directly what syntax rule or constraint it violates.

I can't imagine a valid rationale for refusing to answer that
question, and I find your behavior very frustrating. My frustration
is compounded by the fact that, for whatever reason, you gave no
response at all for several weeks.

I am, for now, convinced that the code in question has undefined
behavior but does not violate any syntax error or constraint.
I respect your technical abilities enough that I'm hesitant to assume
that you're wrong, but that's the only conclusion I can make unless
you choose to explain what you're talking about.

>> Does it occur to you that you would save everyone a lot of time if
>> you'd explain what you mean in the first place?
>
> You say that like you think saving people time should always
> be my highest priority. It isn't, at least not always.
> When there is some tension between two or more areas of
> consideration usually (at least) one has to be shortchanged.
> I prioritize the factors I think are the most important in
> each particular case. I'm sorry if my choices seem poor to
> you but I need to follow the path that I think has the best
> chance of success.

No, I'm not saying saving people time should "always be [your]
highest priority". That's an absurd exaggeration. I'm saying
that it should be one thing for you to consider. You mention the
"best chance of success". Success at what?

I'm having great difficulty reaching a conclusion other than that
you're being rude, inconsiderate, and deliberately evasive, for no
reason that I can discern. I think that's probably not your intent.
I welcome any clarification you can offer.

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

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> On 04/09/2023 12:06, Bart wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> char* fred(void) {
>>>>>>> (long long int)rand()*3.14159;
>>>>>>> }
>>>>>>> int main(void) {
>>>>>>> printf("%s\n", fred());
>>>>>>> }
>>>>>
>>>>> [...]
>>>>>
>>>>>> As you know, it is not valid C code. As you know, proper C
>>>>>> compilers will - at least - warn you about it when asked to
>>>>>> treat the input according to the C standards. As you know,
>>>>>> there isn't a compiler in the world for any language which
>>>>>> will stop programmers from writing incorrect code.
>>>>>
>>>>> Given the context of the discussion, pedantry seems appropriate.
>>>>>
>>>>> It's invalid C code because it doesn't declare rand() and
>>>>> printf(), correctable by adding `#include <stdlib.h>` and
>>>>> `#include <stdio.h>`. (It also contains NO-BREAK SPACE
>>>>> characters, but that's that's just a Usenet formatting issue.)
>>>>>
>>>>> Other than that, a conforming C compiler is not required to
>>>>> diagnose the above code. It does have undefined behavior, and
>>>>> a C compiler is likely to warn about it with appropriate
>>>>> warnings, but it does not violate any syntax rule or
>>>>> constraint.
>>>>
>>>> I say it does.
>>>
>>> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug.
>>> Both compile the above code (once the required #include
>>> directives are added) without error, though clang prints a
>>> couple of optional warnings. I used "-std=c17 -pedantic-errors"
>>> with both compilers. (With "-Wall", gcc prints warnings similar
>>> to the ones clang prints without it.)
>>>
>>> What syntax rule or constraint does it violate?
>>
>> I'm sorry the point I was trying to make got lost. I was
>> hoping for some value to result from my comment, and I feel
>> bad that that is unlikely to happen. I'll try to do better
>> next time.

I am retaining all the above content, even though most of it isn't
relevant to what I have to say, because I don't know how to
summarize it succinctly without losing some essential context.

I realized at some point that my earlier statement was not
understood the way I meant it. Rather than try to go back and
unwind the miscommunication, I decided to just drop it. I
withdraw my earlier statement. Okay?

> I'm sorry you chose not to answer my simple and direct question.
>
> What syntax rule or constraint does the code violate?
>
> Also, what was the point you were trying to make?
>
> I asserted that the code (after adding the required #include
> directives) does not violate any syntax rule or constraint.
> You asserted that it does, but didn't elaborate. I asked you
> directly what syntax rule or constraint it violates.
>
> I can't imagine a valid rationale for refusing to answer that
> question, and I find your behavior very frustrating. My
> frustration is compounded by the fact that, for whatever reason,
> you gave no response at all for several weeks.

Let me say a few things related to the last few paragraphs.

In order to have a useful discussion about a statement or a
question, there needs to be a shared understanding of what the
statement means or what the question is asking. In the absence
of such shared understanding, the discussion is likely to become
difficult, frustrating, unproductive, or worse, or some
combination of the above. I think a lot of our difficulties stem
from not having a shared understanding of the statements or
questions being discussed. Do you see what I mean by that?

On the subject of asking questions, I think anyone in the group
should feel free to pose any question that is asked in good faith
(by which I mean to exclude sentences written in the form of a
question but having a different purpose, and other similar forms
of bad faith "questions"). At the same time, the license to ask
a question does not confer any expectation that one is entitled
to receive any answer. That is the same as with any request. If
someone thinks asking a question obligates the recipient, in any
way, to provide an answer, I must politely demur: it is their
right to ask, it is my right to choose how or whether to answer.

> I am, for now, convinced that the code in question has undefined
> behavior but does not violate any syntax error or constraint. I
> respect your technical abilities enough that I'm hesitant to
> assume that you're wrong, but that's the only conclusion I can
> make unless you choose to explain what you're talking about.

I suggest we both simply forget about it. Probably each of us
misunderstood the other, and it's more trouble than it's worth
(to be clear, in this particular instance) to try to fix that.
Better just to move on.

>>> Does it occur to you that you would save everyone a lot of
>>> time if you'd explain what you mean in the first place?
>>
>> You say that like you think saving people time should always
>> be my highest priority. It isn't, at least not always.
>> When there is some tension between two or more areas of
>> consideration usually (at least) one has to be shortchanged.
>> I prioritize the factors I think are the most important in
>> each particular case. I'm sorry if my choices seem poor to
>> you but I need to follow the path that I think has the best
>> chance of success.
>
> No, I'm not saying saving people time should "always be [your]
> highest priority". That's an absurd exaggeration. I'm saying
> that it should be one thing for you to consider. You mention the
> "best chance of success". Success at what?

Success at whatever I think is most important to accomplish,
which varies a lot depending on circumstances.

> I'm having great difficulty reaching a conclusion other than that
> you're being rude, inconsiderate, and deliberately evasive, for no
> reason that I can discern. I think that's probably not your
> intent. I welcome any clarification you can offer.

I think you have a lot of unconscious assumptions about how
other people see things. Nothing wrong with that, almost
everyone does. Somehow though it seems hard for you to accept
that just because someone has different values than you it
doesn't mean their values are wrong, even though you might not
understand what those values are. You frequently show various
behaviors in the group that I perceive as inconsiderate or rude
or both. I know that you have different values than my own. I
accept what you do as being respectful of various proprieties
and other people, in the frame of your own value system, even
though at times it comes across to me as being tone deaf,
inconsiderate, disrespectful, or rude. It's just part of
different people being different. When in the course of a
discussion it becomes frustrating because of what seems to you
to be rude or inconsiderate behavior, I encourage you to take a
step back from the matter under discussion, and instead try to
discover what differences there may be in the value systems of
the different participants.

[Large block of quoted text, brief reply at the end.]

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>> On 04/09/2023 12:06, Bart wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>> char* fred(void) {
>>>>>>>> (long long int)rand()*3.14159;
>>>>>>>> }
>>>>>>>> int main(void) {
>>>>>>>> printf("%s\n", fred());
>>>>>>>> }
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> As you know, it is not valid C code. As you know, proper C
>>>>>>> compilers will - at least - warn you about it when asked to
>>>>>>> treat the input according to the C standards. As you know,
>>>>>>> there isn't a compiler in the world for any language which
>>>>>>> will stop programmers from writing incorrect code.
>>>>>>
>>>>>> Given the context of the discussion, pedantry seems appropriate.
>>>>>>
>>>>>> It's invalid C code because it doesn't declare rand() and
>>>>>> printf(), correctable by adding `#include <stdlib.h>` and
>>>>>> `#include <stdio.h>`. (It also contains NO-BREAK SPACE
>>>>>> characters, but that's that's just a Usenet formatting issue.)
>>>>>>
>>>>>> Other than that, a conforming C compiler is not required to
>>>>>> diagnose the above code. It does have undefined behavior, and
>>>>>> a C compiler is likely to warn about it with appropriate
>>>>>> warnings, but it does not violate any syntax rule or
>>>>>> constraint.
>>>>>
>>>>> I say it does.
>>>>
>>>> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug.
>>>> Both compile the above code (once the required #include
>>>> directives are added) without error, though clang prints a
>>>> couple of optional warnings. I used "-std=c17 -pedantic-errors"
>>>> with both compilers. (With "-Wall", gcc prints warnings similar
>>>> to the ones clang prints without it.)
>>>>
>>>> What syntax rule or constraint does it violate?
>>>
>>> I'm sorry the point I was trying to make got lost. I was
>>> hoping for some value to result from my comment, and I feel
>>> bad that that is unlikely to happen. I'll try to do better
>>> next time.
>
> I am retaining all the above content, even though most of it isn't
> relevant to what I have to say, because I don't know how to
> summarize it succinctly without losing some essential context.
>
> I realized at some point that my earlier statement was not
> understood the way I meant it. Rather than try to go back and
> unwind the miscommunication, I decided to just drop it. I
> withdraw my earlier statement. Okay?
>
>> I'm sorry you chose not to answer my simple and direct question.
>>
>> What syntax rule or constraint does the code violate?
>>
>> Also, what was the point you were trying to make?
>>
>> I asserted that the code (after adding the required #include
>> directives) does not violate any syntax rule or constraint.
>> You asserted that it does, but didn't elaborate. I asked you
>> directly what syntax rule or constraint it violates.
>>
>> I can't imagine a valid rationale for refusing to answer that
>> question, and I find your behavior very frustrating. My
>> frustration is compounded by the fact that, for whatever reason,
>> you gave no response at all for several weeks.
>
> Let me say a few things related to the last few paragraphs.
>
> In order to have a useful discussion about a statement or a
> question, there needs to be a shared understanding of what the
> statement means or what the question is asking. In the absence
> of such shared understanding, the discussion is likely to become
> difficult, frustrating, unproductive, or worse, or some
> combination of the above. I think a lot of our difficulties stem
> from not having a shared understanding of the statements or
> questions being discussed. Do you see what I mean by that?
>
> On the subject of asking questions, I think anyone in the group
> should feel free to pose any question that is asked in good faith
> (by which I mean to exclude sentences written in the form of a
> question but having a different purpose, and other similar forms
> of bad faith "questions"). At the same time, the license to ask
> a question does not confer any expectation that one is entitled
> to receive any answer. That is the same as with any request. If
> someone thinks asking a question obligates the recipient, in any
> way, to provide an answer, I must politely demur: it is their
> right to ask, it is my right to choose how or whether to answer.
>
>> I am, for now, convinced that the code in question has undefined
>> behavior but does not violate any syntax error or constraint. I
>> respect your technical abilities enough that I'm hesitant to
>> assume that you're wrong, but that's the only conclusion I can
>> make unless you choose to explain what you're talking about.
>
> I suggest we both simply forget about it. Probably each of us
> misunderstood the other, and it's more trouble than it's worth
> (to be clear, in this particular instance) to try to fix that.
> Better just to move on.
>
>
>>>> Does it occur to you that you would save everyone a lot of
>>>> time if you'd explain what you mean in the first place?
>>>
>>> You say that like you think saving people time should always
>>> be my highest priority. It isn't, at least not always.
>>> When there is some tension between two or more areas of
>>> consideration usually (at least) one has to be shortchanged.
>>> I prioritize the factors I think are the most important in
>>> each particular case. I'm sorry if my choices seem poor to
>>> you but I need to follow the path that I think has the best
>>> chance of success.
>>
>> No, I'm not saying saving people time should "always be [your]
>> highest priority". That's an absurd exaggeration. I'm saying
>> that it should be one thing for you to consider. You mention the
>> "best chance of success". Success at what?
>
> Success at whatever I think is most important to accomplish,
> which varies a lot depending on circumstances.
>
>> I'm having great difficulty reaching a conclusion other than that
>> you're being rude, inconsiderate, and deliberately evasive, for no
>> reason that I can discern. I think that's probably not your
>> intent. I welcome any clarification you can offer.
>
> I think you have a lot of unconscious assumptions about how
> other people see things. Nothing wrong with that, almost
> everyone does. Somehow though it seems hard for you to accept
> that just because someone has different values than you it
> doesn't mean their values are wrong, even though you might not
> understand what those values are. You frequently show various
> behaviors in the group that I perceive as inconsiderate or rude
> or both. I know that you have different values than my own. I
> accept what you do as being respectful of various proprieties
> and other people, in the frame of your own value system, even
> though at times it comes across to me as being tone deaf,
> inconsiderate, disrespectful, or rude. It's just part of
> different people being different. When in the course of a
> discussion it becomes frustrating because of what seems to you
> to be rude or inconsiderate behavior, I encourage you to take a
> step back from the matter under discussion, and instead try to
> discover what differences there may be in the value systems of
> the different participants.

Let me offer a brief summary of this discussion.

On 26/10/2023 17:55, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

>> I am, for now, convinced that the code in question has undefined
>> behavior but does not violate any syntax error or constraint. I
>> respect your technical abilities enough that I'm hesitant to
>> assume that you're wrong, but that's the only conclusion I can
>> make unless you choose to explain what you're talking about.
>
> I suggest we both simply forget about it. Probably each of us
> misunderstood the other, and it's more trouble than it's worth
> (to be clear, in this particular instance) to try to fix that.
> Better just to move on.
>

I know you, Tim, either do not read my posts, or you make a specific
point of not replying to them. But in case you do read them, and think
about what I write, I sometimes reply to your posts if I have a
particularly strong opinion or follow-up point.

Your refusal to answer Keith's question and "just move on" post screams
"I was wrong but I won't admit it - I'd rather everyone forgot about
it". You are very rarely wrong on technical issues - perhaps you have
little experience with it. But as someone who knows he makes mistakes
sometimes, I can tell you it is actually a pleasant feeling to say "You
are right Keith, thanks for correcting me - I learned something new
today!". It is even good to say "My gut feeling is that this is a
syntax error, but I can't find any specific rule for now - maybe I'm
wrong, or maybe I'll find the rule in the future, but I'm not
prioritising the search at the moment".

As it stands, you leave me with "I was wrong but I won't admit it" as
the only rational interpretation of your post. I doubt if you care
about the impression you give /me/, but I believe many others will share
that impression - and I don't believe that was the impression you
intended to give. Maybe you will give a better explanation, or maybe
you will just answer Keith's question.

I think everyone can agree that no one here is obligated to answer
questions. But I do think we are all obligated to follow common rules
of decency and respect, as we each see them (being fully aware that such
"rules" are not universal). So we mostly try to avoid accusations,
insults, swearing, etc., and try to have polite and considered
discussions. And I personally think that if a person has made a
provocative post, respect for the poster and the group demands a
reasonable continuation of the conversation - "drive-by shootings" are
not polite. I appreciate that your "once a teacher, always a teacher"
instincts mean you like to give teasers, partial answers and questions
encouraging others to think for themselves. But failing to follow up
(within a reasonable time frame!) these teasers is a failure as a teacher.

>
>>>> Does it occur to you that you would save everyone a lot of
>>>> time if you'd explain what you mean in the first place?
>>>
>>> You say that like you think saving people time should always
>>> be my highest priority. It isn't, at least not always.
>>> When there is some tension between two or more areas of
>>> consideration usually (at least) one has to be shortchanged.
>>> I prioritize the factors I think are the most important in
>>> each particular case. I'm sorry if my choices seem poor to
>>> you but I need to follow the path that I think has the best
>>> chance of success.
>>
>> No, I'm not saying saving people time should "always be [your]
>> highest priority". That's an absurd exaggeration. I'm saying
>> that it should be one thing for you to consider. You mention the
>> "best chance of success". Success at what?
>
> Success at whatever I think is most important to accomplish,
> which varies a lot depending on circumstances.

Such politician answers are not helpful here.

>
>> I'm having great difficulty reaching a conclusion other than that
>> you're being rude, inconsiderate, and deliberately evasive, for no
>> reason that I can discern. I think that's probably not your
>> intent. I welcome any clarification you can offer.
>
> I think you have a lot of unconscious assumptions about how
> other people see things. Nothing wrong with that, almost
> everyone does. Somehow though it seems hard for you to accept
> that just because someone has different values than you it
> doesn't mean their values are wrong, even though you might not
> understand what those values are. You frequently show various
> behaviors in the group that I perceive as inconsiderate or rude
> or both.

I am at a complete loss for how you could get that impression from Keith
(based on his Usenet postings). That we all have different values is
obvious - we are all different people. But of all the adjectives that
could be used to describe Keith, I would never have thought of "rude" or
"inconsiderate". Normally, if someone referred to Keith as frequently
being rude or inconsiderate, I'd assume they were mixing him up with the
other other Keith. In this case, however, I think it is simply that you
do not take well to criticism - Keith openly takes issue with clear
failings in your style of communication, and you respond by accusing him
of being rude, failing to appreciate that you might have different but
valid "values", and of misunderstanding you. (I was put on your naughty
list for pretty much the same "crime".)

> I know that you have different values than my own. I
> accept what you do as being respectful of various proprieties
> and other people, in the frame of your own value system, even
> though at times it comes across to me as being tone deaf,
> inconsiderate, disrespectful, or rude. It's just part of
> different people being different. When in the course of a
> discussion it becomes frustrating because of what seems to you
> to be rude or inconsiderate behavior, I encourage you to take a
> step back from the matter under discussion, and instead try to
> discover what differences there may be in the value systems of
> the different participants.

That sounds like good advice. You should try it yourself.

On 26/10/2023 17:55, Tim Rentsch wrote:
> Keith Thompson <Keith.S.T...@gmail.com> writes:
....
>> I asserted that the code (after adding the required #include
>> directives) does not violate any syntax rule or constraint.
>> You asserted that it does, but didn't elaborate. I asked you
>> directly what syntax rule or constraint it violates.
>>
>> I can't imagine a valid rationale for refusing to answer that
>> question, and I find your behavior very frustrating. My
>> frustration is compounded by the fact that, for whatever reason,
>> you gave no response at all for several weeks.
....
> On the subject of asking questions, I think anyone in the group
> should feel free to pose any question that is asked in good faith
> (by which I mean to exclude sentences written in the form of a
> question but having a different purpose, and other similar forms
> of bad faith "questions"). At the same time, the license to ask
> a question does not confer any expectation that one is entitled
> to receive any answer.

While I can agree with those assertions, the problem predates Keith's
question. Your claim that it does violate a syntax rule or constraint
incurred an obligation to identify the violation, an obligation you
could have most easily fulfilled by doing so immediately after making
the claim. That you failed to do so is the fundamental problem. Keith's
question served merely to remind you of that unfulfilled obligation.
That you failed to respond when reminded is merely a repeat of the
original problem.

I really don't understand why you would claim that there was a syntax
error or constraint violation, and then fail to identify it. I don't see
what purpose such an unsupported claim serves. A supported claim would
serve the purpose of furthering the discussion.

>> I am, for now, convinced that the code in question has undefined
>> behavior but does not violate any syntax error or constraint. I
>> respect your technical abilities enough that I'm hesitant to
>> assume that you're wrong, but that's the only conclusion I can
>> make unless you choose to explain what you're talking about.

I agree - an unsupported claim can serve no other purpose than to
justify that conclusion. Since I doubt that you desired to inspire that
conclusion, I don't see why you failed to support it.

....
>> No, I'm not saying saving people time should "always be [your]
>> highest priority". That's an absurd exaggeration. I'm saying
>> that it should be one thing for you to consider. You mention the
>> "best chance of success". Success at what?
>
> Success at whatever I think is most important to accomplish,
> which varies a lot depending on circumstances.

Which misses the point - he was asking specifically about the
circumstances of this particular unsupported claim.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
> I see now it was a bad idea to send my last message via
> a public forum. If you send me an email I will try to
> send you a reply.

I posted an assertion publicly, that a certain piece of code violates
no constraints or syntax rules. You publicly claimed that it does.
I publicly asked you to back up your claim. I see no reason to
conduct further discussion about this C technical issue in private.
At this point, I have nothing to say in email that I haven't already
said here.

Feel free to email me if you like. If you specifically ask me not
to share whatever you say to me in email, I will comply; otherwise
I reserve the right to quote it here if I think it's topical.

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

On 2023-11-18 at 00:17 EST, Tim Rentsch wrote:
> 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.

The question he was referring to was the very last sentence of the
following text, which comes from a message posted on the thread titled
"bart again (UCX64)". You never answered it. Keith posted three more
messages on that subthread repeating the question and asking why you had
not bothered answering it. You answered with the same useless comments
about needing a "shared understanding of what the statement means" that
you're using in this thread. What makes those comments useless is not
that they are wrong, but that you failed to explain what understanding
you think is not shared between you and Keith. Because you failed to
explain that, I have no idea why you think it's needed to answer a
simple straightforward question like the following:

On 9/4/23 21:57, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 04/09/2023 12:06, Bart wrote:
>>> [...]
>>>
>>>>> char* fred(void) {
>>>>> (long long int)rand()*3.14159;
>>>>> }
>>>>> int main(void) {
>>>>> printf("%s\n", fred());
>>>>> }
>>>
>>> [...]
>>>
>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>> will - at least - warn you about it when asked to treat the input
>>>> according to the C standards. As you know, there isn't a compiler in
>>>> the world for any language which will stop programmers from writing
>>>> incorrect code.
>>>
>>> Given the context of the discussion, pedantry seems appropriate.
>>>
>>> It's invalid C code because it doesn't declare rand() and printf(),
>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>> Usenet formatting issue.)
>>>
>>> Other than that, a conforming C compiler is not required to diagnose
>>> the above code. It does have undefined behavior, and a C compiler is
>>> likely to warn about it with appropriate warnings, but it does not
>>> violate any syntax rule or constraint.
>>
>> I say it does.

That would have been the correct place to identify the syntax rule or
constraint you think it violates, and I have no idea why you failed to
do so.

> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
> compile the above code (once the required #include directives are added)
> without error, though clang prints a couple of optional warnings. I used
> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
> prints warnings similar to the ones clang prints without it.)
>
> What syntax rule or constraint does it violate?

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2023-11-18 at 00:17 EST, Tim Rentsch wrote:
>> 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.
>
> The question he was referring to was the very last sentence of the
> following text, which comes from a message posted on the thread titled
> "bart again (UCX64)". You never answered it. Keith posted three more
> messages on that subthread repeating the question and asking why you had
> not bothered answering it. You answered with the same useless comments
> about needing a "shared understanding of what the statement means" that
> you're using in this thread. What makes those comments useless is not
> that they are wrong, but that you failed to explain what understanding
> you think is not shared between you and Keith. Because you failed to
> explain that, I have no idea why you think it's needed to answer a
> simple straightforward question like the following:
>
> On 9/4/23 21:57, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 04/09/2023 12:06, Bart wrote:
>>>> [...]
>>>>
>>>>>> char* fred(void) {
>>>>>> (long long int)rand()*3.14159;
>>>>>> }
>>>>>> int main(void) {
>>>>>> printf("%s\n", fred());
>>>>>> }
>>>>
>>>> [...]
>>>>
>>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>>> will - at least - warn you about it when asked to treat the input
>>>>> according to the C standards. As you know, there isn't a compiler in
>>>>> the world for any language which will stop programmers from writing
>>>>> incorrect code.
>>>>
>>>> Given the context of the discussion, pedantry seems appropriate.
>>>>
>>>> It's invalid C code because it doesn't declare rand() and printf(),
>>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>>> Usenet formatting issue.)
>>>>
>>>> Other than that, a conforming C compiler is not required to diagnose
>>>> the above code. It does have undefined behavior, and a C compiler is
>>>> likely to warn about it with appropriate warnings, but it does not
>>>> violate any syntax rule or constraint.
>>>
>>> I say it does.
>
> That would have been the correct place to identify the syntax rule or
> constraint you think it violates, and I have no idea why you failed to
> do so.
>
>> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
>> compile the above code (once the required #include directives are added)
>> without error, though clang prints a couple of optional warnings. I used
>> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
>> prints warnings similar to the ones clang prints without it.)
>>
>> What syntax rule or constraint does it violate?

Yes, that is the question I was referring to. To repeat, given this
code:

char* fred(void) {
(long long int)rand()*3.14159;
}

int main(void) {
printf("%s\n", fred());
}

I asserted that it does not violate any syntax rule or constraint.
You asserted, with no explanation, that it does.

What syntax rule or constraint does it violate?

(Optional followup question: Why didn't you answer that when I first
asked it two and a half months ago?)

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

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

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 2023-11-18 at 00:17 EST, Tim Rentsch wrote:
>>
>>> 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.
>>
>> The question he was referring to was the very last sentence of the
>> following text, which comes from a message posted on the thread titled
>> "bart again (UCX64)". You never answered it. Keith posted three more
>> messages on that subthread repeating the question and asking why you had
>> not bothered answering it. You answered with the same useless comments
>> about needing a "shared understanding of what the statement means" that
>> you're using in this thread. What makes those comments useless is not
>> that they are wrong, but that you failed to explain what understanding
>> you think is not shared between you and Keith. Because you failed to
>> explain that, I have no idea why you think it's needed to answer a
>> simple straightforward question like the following:
>>
>> On 9/4/23 21:57, Keith Thompson wrote:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> On 04/09/2023 12:06, Bart wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> char* fred(void) {
>>>>>>> (long long int)rand()*3.14159;
>>>>>>> }
>>>>>>> int main(void) {
>>>>>>> printf("%s\n", fred());
>>>>>>> }
>>>>>
>>>>> [...]
>>>>>
>>>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>>>> will - at least - warn you about it when asked to treat the input
>>>>>> according to the C standards. As you know, there isn't a compiler in
>>>>>> the world for any language which will stop programmers from writing
>>>>>> incorrect code.
>>>>>
>>>>> Given the context of the discussion, pedantry seems appropriate.
>>>>>
>>>>> It's invalid C code because it doesn't declare rand() and printf(),
>>>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>>>> Usenet formatting issue.)
>>>>>
>>>>> Other than that, a conforming C compiler is not required to diagnose
>>>>> the above code. It does have undefined behavior, and a C compiler is
>>>>> likely to warn about it with appropriate warnings, but it does not
>>>>> violate any syntax rule or constraint.
>>>>
>>>> I say it does.
>>
>> That would have been the correct place to identify the syntax rule or
>> constraint you think it violates, and I have no idea why you failed to
>> do so.
>>
>>> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
>>> compile the above code (once the required #include directives are added)
>>> without error, though clang prints a couple of optional warnings. I used
>>> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
>>> prints warnings similar to the ones clang prints without it.)
>>>
>>> What syntax rule or constraint does it violate?
>
> Yes, that is the question I was referring to. [...]

I did answer. If you don't like my answer that's your
problem, not mine.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 2023-11-18 at 00:17 EST, Tim Rentsch wrote:
>>>> 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.
>>>
>>> The question he was referring to was the very last sentence of the
>>> following text, which comes from a message posted on the thread titled
>>> "bart again (UCX64)". You never answered it. Keith posted three more
>>> messages on that subthread repeating the question and asking why you had
>>> not bothered answering it. You answered with the same useless comments
>>> about needing a "shared understanding of what the statement means" that
>>> you're using in this thread. What makes those comments useless is not
>>> that they are wrong, but that you failed to explain what understanding
>>> you think is not shared between you and Keith. Because you failed to
>>> explain that, I have no idea why you think it's needed to answer a
>>> simple straightforward question like the following:
>>>
>>> On 9/4/23 21:57, Keith Thompson wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>
>>>>>>> On 04/09/2023 12:06, Bart wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>> char* fred(void) {
>>>>>>>> (long long int)rand()*3.14159;
>>>>>>>> }
>>>>>>>> int main(void) {
>>>>>>>> printf("%s\n", fred());
>>>>>>>> }
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> As you know, it is not valid C code. As you know, proper C compilers
>>>>>>> will - at least - warn you about it when asked to treat the input
>>>>>>> according to the C standards. As you know, there isn't a compiler in
>>>>>>> the world for any language which will stop programmers from writing
>>>>>>> incorrect code.
>>>>>>
>>>>>> Given the context of the discussion, pedantry seems appropriate.
>>>>>>
>>>>>> It's invalid C code because it doesn't declare rand() and printf(),
>>>>>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>>>>>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>>>>>> Usenet formatting issue.)
>>>>>>
>>>>>> Other than that, a conforming C compiler is not required to diagnose
>>>>>> the above code. It does have undefined behavior, and a C compiler is
>>>>>> likely to warn about it with appropriate warnings, but it does not
>>>>>> violate any syntax rule or constraint.
>>>>>
>>>>> I say it does.
>>>
>>> That would have been the correct place to identify the syntax rule or
>>> constraint you think it violates, and I have no idea why you failed to
>>> do so.
>>>
>>>> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
>>>> compile the above code (once the required #include directives are added)
>>>> without error, though clang prints a couple of optional warnings. I used
>>>> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
>>>> prints warnings similar to the ones clang prints without it.)
>>>>
>>>> What syntax rule or constraint does it violate?
>>
>> Yes, that is the question I was referring to. [...]
>
> I did answer. If you don't like my answer that's your
> problem, not mine.

In this thread, in the first quoted paragraph in this post, you
asked me to repeat a question that I had asked before. I did so.
It was a simple question, not a matter of opinion, not an invitation
to an argument.

I am now asking you to repeat your answer to that question (or
rather to answer it in the first place).

You have not so far answered the question. An answer would
have included a citation of a specific syntax rule or constraint
(including the section, subsection, and paragraph number in some
edition or draft of the ISO C standard) that is violated by the
program quoted above.

It's possible that I'm mistaken, and that you have actually
answered the question. If you demonstrate that, I will acknowledge
my mistake.

I will not ask again.

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
....
>>> On 11/18/23 08:44, Keith Thompson wrote:
....
>>>> What syntax rule or constraint does it violate?
>>
>> Yes, that is the question I was referring to. [...]
>
> I did answer. If you don't like my answer that's your
> problem, not mine.

I saw a response, several of them in fact, but none of those responses
contained an answer. An answer would identify the relevant syntax rule
or constraint - none of your responses identified any syntax error or
constraint violation. All I saw was responses that gave bad excuses for
not bothering to answer the question.

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.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
> ...
>
>>>> On 11/18/23 08:44, Keith Thompson wrote:
>
> ...
>
>>>>> What syntax rule or constraint does it violate?
>>>
>>> Yes, that is the question I was referring to. [...]
>>
>> I did answer. If you don't like my answer that's your
>> problem, not mine.
>
> I saw a response, several of them in fact, but none of those responses
> contained an answer. An answer would identify the relevant syntax rule
> or constraint - none of your responses identified any syntax error or
> constraint violation. All I saw was responses that gave bad excuses for
> not bothering to answer the question.

I suggest you look up the word "answer" in an English dictionary
rather than a James Kuyper dictionary. I did answer.

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.

You actually seem to believe that. I no longer care.

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

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?

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

[...]

> I was somewhat disappointed when I did look it up. [...] 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." [...]
> 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.

The American Heritage Dictionary of the English Language, 5th Edition,
seems to provide the definition you want, but as a second and third
option. It's unclear what they mean with the order.

--8<---------------cut here---------------start------------->8---
A spoken or written reply, as to a question.
A correct reply.
A solution, as to a problem.

Source:
The American Heritage Dictionary of the English Language, 5th Edition
--8<---------------cut here---------------end--------------->8---

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. The [last] answer had actually been on a meta level; it seems to
say that the poster missed the informational content of the replies.
That may be true or not. If it is true the requester may re-read the
posts. Or maybe the responder has missed that the answer is either not
sufficient or missed the point (or something else). And here Shannon
pops in; every single information transfer (requests and responses) is
affected by Equivocation H(X|Y) and Irrelevance H(Y|X). But even if the
Mutual Information I(X;Y) is maximized it may still not be sufficient
to help for the posters request.

Neither dictionaries nor information theory helps to answer the posted
questions, but understanding Shannon's theories - which nicely maps to
social communication! - might prevent widely meaningless and redundant
transfers like "You have not answered" and "I did answer". :-)

Janis