Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.lang.c++,comp.lang.c Subject: Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Date: Fri, 24 May 2024 12:03:04 -0500 Organization: A noiseless patient Spider Lines: 87 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 24 May 2024 19:03:04 +0200 (CEST) Injection-Info: dont-email.me; posting-host="853a48eea7a3e841565c364baea8e5bf"; logging-data="2549243"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/L1GcZF1HgT31QCQyEk5zZ" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:DR85MehKTl0+1OfNO2++NKsO10A= Content-Language: en-US In-Reply-To: Bytes: 4227 On 5/24/2024 8:37 AM, David Brown wrote: > On 24/05/2024 15:08, olcott wrote: >> On 5/24/2024 7:10 AM, Richard Harnden wrote: >>> On 23/05/2024 17:52, olcott wrote: >>>> typedef int (*ptr)();  // ptr is pointer to int function in C >>>> 00       int H(ptr p, ptr i); >>>> 01       int D(ptr p) >>>> 02       { >>>> 03         int Halt_Status = H(p, p); >>>> 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       } >>>> >>>> The above template refers to an infinite set of H/D pairs where D is >>>> correctly simulated by pure function H. This was done because many >>>> reviewers used the shell game ploy to endlessly switch which H/D was >>>> being referred to. >>>> >>>> *Correct Simulation Defined* >>>> This is provided because every reviewer had a different notion of >>>> correct simulation that diverges from this notion. >>>> >>>> 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); H(D,D) simulates lines 01, 02, and >>>> 03 of >>>> D. This invokes H(D,D) again to repeat the process in endless recursive >>>> simulation. >>> >>> >>> So, you have: main -> H -> D -> H -> D -> ... -> H -> D until you run >>> out of stack? >>> >>> No return statement is ever reached. >>> Line 3 never completes. >>> Halt_Status at line 3 never gets a value. >>> >>> >>> >>> >> Thanks. >> >> Proving that D correctly simulated by H never reaches its final >> state at line 06 and halts. > > No, it does not. > > As Richard says, you have main -> H -> D -> H -> ... > > For any finite system, you will run out of stack space.  This is > undefined behaviour in C.  /Anything/ can happen - including halting, > returning a halt status of 1, or a halt status of 0, or a not halting, > or printing out the works of Shakespeare.  Or it could cause the program > to jump directly to line 6.  Once you hit undefined behaviour, you > cannot prove /anything/. > Abnormal termination does not count as halting. The software engineering equivalent of the theory of computation term: D {halts} is D {terminates normally}. >> Thus proving that the halting problem's >> counter-example input D would be correctly determined to be non-halting >> by its simulating termination analyzer H. >> > -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer