Re: Can you please verify that the analysis of these C functions is correct?

On 6/22/24 12:36 PM, olcott wrote:

On 6/22/2024 8:58 AM, Richard Damon wrote:

On 6/22/24 8:42 AM, olcott wrote:

On 6/22/2024 5:13 AM, Richard Harnden wrote:

On 21/06/2024 22:41, olcott wrote:

On 6/17/2024 9:11 AM, Bonita Montero wrote:

Am 17.06.2024 um 05:47 schrieb olcott:

To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
>
typedef void (*ptr)();
int H0(ptr P);
>
void Infinite_Loop()
{
   HERE: goto HERE;
}
>
void Infinite_Recursion()
{
   Infinite_Recursion();
}
>
void DDD()
{
   H0(DDD);
   return;
}
>
int main()
{
   H0(Infinite_Loop);
   H0(Infinite_Recursion);
   H0(DDD);
}
>
Every C programmer that knows what an x86 emulator is knows that when H0
emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate
normally.
>
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
>
*My POD24 diagnosis is reducing the time I have left to work on this*
Validation of POD24 as a robust early clinical end point of poor
survival in FL from 5225 patients on 13 clinical trials
https://pubmed.ncbi.nlm.nih.gov/34614146/
>

>
Everything correct, no further questions allowed.
>

>
Thanks for your help on this. The Liars on comp.theory are
even lying about what you actually said.
>

>
Pretty sure that Bonita was taking the piss.
>

I would say that this would indicate that you are insufficiently
competent with the C programming language.
>

>
It seems you are the one that doesn't know the C programing language. After all, you didn't know about the unordering of sub-expressions, or that this can lead to undefined behavior.

 It seems pretty stupid to allow gaps in the semantics of C++ programs. Simply specify that the order of evaluation is left to right unless:
(a) Otherwise specified such as operator precedence rules.
(b) Derives the same result as left to right ordering.
 

Nope. The problem is that such a rule breaks the fundamental design decisions that the goal is to make it possible to create as efficient machine code as possible.
If you need the left to right evaluation order, there are ways to write the code to make that happen.
One of the fundamental design decisions in the language is that it trusts the programmer to know the rules, and will strive for the fastest code possible.
C++ made a special rule for the << operator because the gain for its use as an output was high enough, and the cost as a normal shift operator was rarely high (and normally hidden by the "as if" rule) so it was done there.
There are too many cases for the more general arguement that causes measurable speed differences.