Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: Can someone please verify the execution trace of this?
Date: Mon, 20 May 2024 14:07:52 -0500
Organization: A noiseless patient Spider
Lines: 201
Message-ID: <v2g728$4nu0$2@dont-email.me>
References: <v2b78t$2vima$1@dont-email.me>
 <v2df79$3ghfd$1@raubtier-asyl.eternal-september.org>
 <v2di7v$3gujt$1@dont-email.me>
 <v2eada$3p6sk$1@raubtier-asyl.eternal-september.org>
 <v2edbr$3pl2i$1@dont-email.me>
 <eaa0ef93ca03f744edc4fbcf6e79fc730805cce9.camel@gmail.com>
 <v2fom7$1pfh$1@dont-email.me>
 <32565d46f03edef2380267eeb552fcce102e6753.camel@gmail.com>
 <v2g0vb$3j0c$2@dont-email.me>
 <239b5d6057b5b9d7b63d62235fac97facb039718.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 20 May 2024 21:07:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="629f9cefad5d4023792ce8f8ed8d9594";
	logging-data="155584"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+pgZyijdj9EIuhFeCQ070f"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hQY+4s6/ZNN9yg8qhbM5YSB2opE=
In-Reply-To: <239b5d6057b5b9d7b63d62235fac97facb039718.camel@gmail.com>
Content-Language: en-US
Bytes: 8840

On 5/20/2024 1:23 PM, wij wrote:
> On Mon, 2024-05-20 at 12:23 -0500, olcott wrote:
>> On 5/20/2024 11:21 AM, wij wrote:
>>> On Mon, 2024-05-20 at 10:02 -0500, olcott wrote:
>>>> On 5/20/2024 7:37 AM, wij wrote:
>>>>> On Sun, 2024-05-19 at 21:43 -0500, olcott wrote:
>>>>>> On 5/19/2024 8:52 PM, Bonita Montero wrote:
>>>>>>> Am 19.05.2024 um 21:00 schrieb olcott:
>>>>>>>> On 5/19/2024 1:08 PM, Bonita Montero wrote:
>>>>>>>>> Am 18.05.2024 um 23:40 schrieb olcott:
>>>>>>>>>> People are saying that they have no idea what this code does
>>>>>>>>>> because they do not believe it conforms to c11 or c17.
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>>>>>>> 00 int H(ptr x, ptr y);
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> *Execution Trace*
>>>>>>>>>> Line 11: main() invokes H(D,D);
>>>>>>>>>>
>>>>>>>>>> *keeps repeating* (unless aborted)
>>>>>>>>>> Line 01:
>>>>>>>>>> Line 02:
>>>>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>>>>>
>>>>>>>>>> *Simulation invariant*
>>>>>>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>>>>>>>
>>>>>>>>>> The key thing to note is that no D correctly simulated by any H of
>>>>>>>>>> every
>>>>>>>>>> H/D pair specified by the above template ever reaches its own line 06
>>>>>>>>>> and halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Other people think 30s about this, you think years about that.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is the basis for my two decades long primary research into
>>>>>>>> termination analysis. People on another forum have written
>>>>>>>> hundreds of posts claiming that D correctly simulated by H
>>>>>>>> reaches its own line 06 and halts.
>>>>>>>>
>>>>>>>> *I have only gotten truthful answers on this forum*
>>>>>>>>
>>>>>>>
>>>>>>> That's not research, that's nonsense.
>>>>>>>
>>>>>>
>>>>>> This is not the forum to show that it is not nonsense this is
>>>>>> a simple C question that I should not even have to ask except
>>>>>> for a few people in another forum that consistently lie about
>>>>>> the answer.
>>>>>>
>>>>>> I have been a professional C++ developer since Y2K. So I already
>>>>>> know the answer, I just need some competent people in this forum
>>>>>> to attest to this answer. I met Bjarne Stroustrup back when he
>>>>>> was going around the country promoting his new language.
>>>>>>
>>>>>
>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>> int H(ptr x, ptr y);
>>>>> int D(ptr x)
>>>>> {
>>>>>      int Halt_Status = H(x, x);
>>>>>      if (Halt_Status)
>>>>>        HERE: goto HERE;
>>>>>      return Halt_Status;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      H(D,D);
>>>>>      return 0;
>>>>> }
>>>>>
>>>>> The code above does not compile:
>>>>
>>>> *It does compile*
>>>> *It does compile*
>>>> *It does compile*
>>>> *It does compile*
>>>>
>>>> typedef int (*ptr)();
>>>> int H(ptr P, ptr I);
>>>>
>>>> int D(ptr x)
>>>> {
>>>>      int Halt_Status = H(x, x);
>>>>      if (Halt_Status)
>>>>        HERE: goto HERE;
>>>>      return Halt_Status;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>      H(D,D);
>>>>      return 0;
>>>> }
>>>>
>>>> cl  /GS- /std:c11 /c /arch:IA32 Test_Compile.c
>>>> cl  /GS- /std:c17 /c /arch:IA32 Test_Compile.c
>>>> if ERRORLEVEL 1 pause
>>>>
>>>>
>>>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>echo
>>>> off
>>>>
>>>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>REM
>>>> 2022
>>>>
>>>> D:\__HP_Stream\__NLU_Notes\__Work_In_Progress\__Halt_Decider_X86\___x86utm_VS>call
>>>> "C:\Program Files\Microsoft Visual
>>>> Studio\2022\Community\Common7\Tools\VsDevCmd.BAT"
>>>> **********************************************************************
>>>> ** Visual Studio 2022 Developer Command Prompt v17.6.4
>>>> ** Copyright (c) 2022 Microsoft Corporation
>>>> **********************************************************************
>>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
>>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>>
>>>> Test_Compile.c
>>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x86
>>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>>
>>>> Test_Compile.c
>>>> Press any key to continue . . .
>>>
>>> OK, My fault, gcc can compile (g++ can't. No idea why D's protocol doesn't match
>>> type ptr and get compiled in C).
>>>
>>
>>
>> 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.
>>
>> *I just need to people that have persistently lied*
>> *about this for two years to be put in their place*
>>
>> *Can you see that*
>> For every H/D pair of the above template D correctly simulated by pure
>> function (thus computable function) H cannot possibly reach its own
>> final state at line 06 and halt.
> 
> People understand "H cannot possibly reach its own final state at line 06
========== REMAINDER OF ARTICLE TRUNCATED ==========