Deutsch English Français Italiano |
<v2i8gs$jvcs$4@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: Every D(D) simulated by H presents non-halting behavior to H ### Date: Tue, 21 May 2024 08:44:59 -0500 Organization: A noiseless patient Spider Lines: 135 Message-ID: <v2i8gs$jvcs$4@dont-email.me> References: <v18e32$1vbql$1@dont-email.me> <v1cla9$34iis$1@dont-email.me> <v1d2mi$9f72$11@i2pn2.org> <v1di1h$3b2m5$1@dont-email.me> <v1dtdv$3dqg4$1@dont-email.me> <v1du2i$3dt7u$1@dont-email.me> <v1fetd$3s7jo$1@dont-email.me> <v1ft42$3vdau$2@dont-email.me> <-5Gdnf-nQvstC6b7nZ2dnZfqnPadnZ2d@brightview.co.uk> <v1gid8$4ilc$1@dont-email.me> <v1h9eu$9faf$1@dont-email.me> <v1iqli$nsva$1@dont-email.me> <v1ln3c$vfh$1@news.muc.de> <v1s6e6$397iq$2@dont-email.me> <v1slmi$3cjtp$1@dont-email.me> <v1t8tt$3gu9t$3@dont-email.me> <v1vc8j$3jmr$1@dont-email.me> <v1vsru$7eqc$1@dont-email.me> <v21r4i$otc2$2@dont-email.me> <v22k4b$umr4$1@dont-email.me> <v24oah$1h4u3$1@dont-email.me> <v256fc$1kais$1@dont-email.me> <v27d05$25ga0$1@dont-email.me> <v2838r$29rd7$1@dont-email.me> <v2a8th$2ps09$1@dont-email.me> <v2ahqc$2qvr9$1@dont-email.me> <v2cb5s$39fvg$1@dont-email.me> <v2crk0$3cifp$1@dont-email.me> <v2cvuo$3dfkm$1@dont-email.me> <v2d0qm$3ddo5$3@dont-email.me> <v2f15t$3t14c$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 21 May 2024 15:45:00 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2f5f52f96f067406075e702eab09af4a"; logging-data="654748"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ftZThiGER8ErKQtl3ClWR" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:l1M1LKvipJy0vX94ZVhaClrTH9Y= Content-Language: en-US In-Reply-To: <v2f15t$3t14c$1@dont-email.me> Bytes: 6943 On 5/20/2024 3:21 AM, Mikko wrote: > On 2024-05-19 14:03:01 +0000, olcott said: > >> On 5/19/2024 8:48 AM, Mikko wrote: >>> On 2024-05-19 12:34:08 +0000, olcott said: >>> >>>> On 5/19/2024 2:53 AM, Mikko wrote: >>>>> On 2024-05-18 15:34:36 +0000, James Kuyper said: >>>>> >>>>>> On 5/18/24 09:02, Mikko wrote: >>>>>>> On 2024-05-17 17:14:01 +0000, olcott said: >>>>>> >>>>>> I recommend ignoring olcott - nothing good ever comes from paying >>>>>> attention to him. >>>>>> >>>>>>>> On 5/17/2024 5:53 AM, Mikko wrote: >>>>>>>>> On 2024-05-16 14:50:19 +0000, olcott said: >>>>>>>>> >>>>>>>>>> On 5/16/2024 5:48 AM, Mikko wrote: >>>>>>>>>>> On 2024-05-15 15:24:57 +0000, olcott said: >>>>>> ... >>>>>>>>>>>> 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 } >>>>>>>>>>> >>>>>>>>>>> Can you find any compiler that is liberal enough to accept that? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It has been fully operational code under Windows and >>>>>>>>>> Linux for two years. >>>>>>>>> >>>>>>>>> If your compiler does not reject that program it is not a >>>>>>>>> conforming >>>>>>>>> C compiler. The semantics according to C standard is that a >>>>>>>>> diagnostic >>>>>>>>> message must be given. The standard does not specify what >>>>>>>>> happens if >>>>>>>>> you execute that program anyway. >>>>>>>>> >>>>>>>> >>>>>>>> It is not nit picky syntax that is the issue here. >>>>>>>> The SEMANTICS OF THE C PROGRAMMING LANGUAGE SPECIFIES >>>>>>>> >>>>>>>> No D simulated correctly by any H of every H/D pair specified >>>>>>>> by the above template ever reaches its own line 06 and halts. >>>>>>> >>>>>>> The standard allows that an program is executed but does not >>>>>>> specify what happens when an invalid program is executed. >>>>>> >>>>>> You've cross-posted this to comp.lang.c after a long-running >>>>>> discussion >>>>>> solely on comp.theory. Presumably you're doing that because you want >>>>>> some discussion about what the standard says about this code. For the >>>>>> sake of those of us who have not been following that discussion on >>>>>> comp.theory, could you please identify what it is that you think >>>>>> renders >>>>>> this code invalid? Offhand, I don't see anything wrong with it, >>>>>> but I'm >>>>>> far more reliable when I say "I see an error" than when I say "I >>>>>> don't >>>>>> see an error". >>>>>> >>>>>> >>>>>>>> Fully operational software that runs under Widows and Linux >>>>>>>> proves that the above is true EMPIRICALLY. >>>>>>> >>>>>>> No, it does not. As the program is not strictly comforming >>>>>>> and uses a non-standard extension some implementation may >>>>>>> execute it differently or refuse to execute. >>>>>> >>>>>> Which non-standard extension does it use? >>>>> >>>>> The main question is whether both arguments of H on the line 00 can >>>>> have >>>>> the same name. >>>> >>>> That was a typo that I did not believe when told because so may people >>>> continue to lie about the behavior of D correctly simulated by H. >>> >>> How does the D that is correctly simulated by H different from any >>> D that is incorrectly simulated by H nor not simulated by H? > > Oops, I made a typo on the last line. Pro "nor" lege "or". > Fortunately most of the typos are harmless but this one > might be a problem. > >> typedef int (*ptr)(); // ptr is pointer to int function >> 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 } >> >> 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. > > As far as I can see, that does not say anything that was not already > said (but there is a minor presentational imporvement) and in particular > does not answer my question. > The problem is that people continue to refuse to answer the updated question and the original question. Everyone spends enormous effort on not answering either question. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer