Re: Every D correctly simulated by H never reaches its final state and halts

On 5/17/24 1:46 PM, olcott wrote:

On 5/17/2024 11:00 AM, Mikko wrote:

On 2024-05-17 15:30:01 +0000, olcott said:
>

On 5/17/2024 2:25 AM, Fred. Zwarts wrote:

Op 17.mei.2024 om 03:15 schreef olcott:

The following is self-evidently true on the basis of the
semantics of the C programming language.
>
typedef int (*ptr)();  // ptr is pointer to int function
00 int H(ptr x, ptr x);
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12   return 0;
13 }
>
In the above case a simulator is an x86 emulator that correctly
emulates at least one of the x86 instructions of D in the order
specified by the x86 instructions of D.
>
This may include correctly emulating the x86 instructions of H
in the order specified by the x86 instructions of H thus calling
H(D,D) in recursive simulation.
>
Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach its own line 06 and halt.
>
*This is a simple software engineering verified fact*
>

>
Note that olcott defines 'verified fact' as 'proven fact', but he is unable to show the proof. So, it must be read as 'my belief'.

>
It is self-evidently true to anyone having sufficient knowledge
of the semantics of the C programming language.

>
No, it isn't, because the C code of H is not shown.

 *I DON'T KNOW WHY I MUST REPEAT THIS HUNDREDS OF TIMES*
The C code that <is> shown provides the template for the
infinite set of every D correctly simulated by H.

But. I have shown how to right code for H that makes your claim false.
This means that you don't have the needed knowledge of the C programming language, or about what truth actually is.
And the fact that you refuse to take up any of my challenges to have me repost the link (because you clearly prefer to just lie rather that try to do some research) it is clear that you are not actually certain of your claim, so you know you may be lying, but you do it anyway.

 

The actual
implementation of H as decribed in some earlier messages is
not fully encoded in standard C, so in order to understand the
behaviour of D one needs to know and understand something that
is not given as a C code and therefore not understandable from
mere knowing the C language definition.
>

 *SUFFICIENTLY KNOWING THE SEMANTICS OF C*
*SUFFICIENTLY KNOWING THE SEMANTICS OF C*
*SUFFICIENTLY KNOWING THE SEMANTICS OF C*

Which you don't seem to have, since you claim prove false statements about it.

 I could cast uint32_t to and from the various function pointer
types yet this is more difficult for people to understand.
I got complaints about this.
It is simpler and easier to do this: typedef int (*ptr)();