Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory,comp.lang.c Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Followup-To: comp.theory Date: Thu, 8 May 2025 22:34:35 -0500 Organization: A noiseless patient Spider Lines: 187 Message-ID: References: <87msbmeo3b.fsf@nosuchdomain.example.com> <87a57mek8r.fsf@nosuchdomain.example.com> <87seled0zy.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 09 May 2025 05:34:35 +0200 (CEST) Injection-Info: dont-email.me; posting-host="b8226b0a928845ead4a9adb4b3b34c7d"; logging-data="2646265"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FdXMindY4GDLku4AwdDh/" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:cswucIYiyiuaCKdGHnfPn6uNg7M= In-Reply-To: X-Antivirus: Norton (VPS 250508-4, 5/8/2025), Outbound message Content-Language: en-US X-Antivirus-Status: Clean Bytes: 8894 On 5/8/2025 10:14 PM, Mike Terry wrote: > On 09/05/2025 03:13, olcott wrote: >> On 5/8/2025 8:30 PM, Keith Thompson wrote: >>> olcott writes: >>>> On 5/8/2025 6:49 PM, Keith Thompson wrote: >>>>> olcott writes: >>>>> [...] >>>>>> void DDD() >>>>>> { >>>>>>     HHH(DDD); >>>>>>     return; >>>>>> } >>>>>> >>>>>> If you are a competent C programmer then you >>>>>> know that DDD correctly simulated by HHH cannot >>>>>> possibly each its own "return" instruction. >>>>> "cannot possibly each"? >>>>> I am a competent C programmer (and I don't believe you can make >>>>> the same claim).  I don't know what HHH is.  The name "HHH" tells >>>>> me nothing about what it's supposed to do.  Without knowing what >>>>> HHH is, I can't say much about your code (or is it pseudo-code?). >>>>> >>>> >>>> For the purpose of this discussion HHH is exactly >>>> what I said it is. It correctly simulates DDD. >>> >>> Does HHH correctly simulate DDD *and do nothing else*? >>> >>> Does HHH correctly simulate *every* function whose address is passed >>> to it?  Must the passed function be one that takes no arguments >>> and does not return a value? >>> >>> Can HHH just *call* the function whose address is passed to it? >>> If it's a correct simulation, there should be no difference between >>> calling the function and "correctly simulating" it. >>> >>> My knowledge of C tells me nothing about *how* HHH might simulate >>> DDD. >>> >> >> HHH can only simulate a function that take no arguments >> and has no return value. HHH also simulates the entire >> chain of functions that this function calls. These can >> take arguments or not and have return values or not. >> >> Thus HHH ends up simulating itself (and everything >> that HHH calls) simulating DDD in an infinite >> sequence of recursive emulation until OOM error. >> >>>> We need not know anything else about HHH to >>>> know that DDD correctly simulated by HHH cannot >>>> possibly REACH its own "return" instruction. >>> >>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>> does nothing else, your code would be equivalent to this: >>> >>>      void DDD(void) { >>>          DDD(); >>>          return; >>>      } >>> >> >> Exactly. None of these people on comp.theory could >> get that even after three years. >> > > PO is being quite deceptive here. > I am only referring to the above hypothetical HHH/DDD pair. Everyone here has consistently denied that when DDD is correctly simulated by HHH that this DDD cannot possibly reach its "return" instruction (final halt state). > His simulation is in fact a single-stepped x86 instruction simulation, > where the stepping of each x86 instruction is under the HHH's control. > HHH can continue stepping the simulation until its target returns, in > which case the situation is logically just like direct call, as you have > described.  Or HHH could step just 3 x86 instructions (say) and then > decide to return (aka "abort" its simulation).  Let's call that / > partial/ simulation in contrast with /full/ simulation which you've been > supposing. > A full simulation of infinite recursion? I am only doing one tiny idea at a time here. > Oh, did he forget to mention that?  Anyhow, in the general case with / > partial/ simulation there is more to think about as it is obvioudly / > not/ logically equivalent to direct execution. > That is changing the subject away from DDD correctly simulated by HHH. > > Oh, and obviously everybody in comp.theory gets all this.  The problem > is with PO and his inability to communicate his ideas properly and his > inability to understand what other people understand or disagree with. > He goes on for months/years claiming people don't understand things they > agree with, but it's down to his duffer wording... > >>> Then the return statement (which is unnecessary anyway) will never be >>> reached. >> >> It is only there to mark a final halt state. >> >>> In practice, the program will likely crash due to a stack >>> overflow, unless the compiler implements tail-call optimization, in >>> which case the program might just run forever -- which also means the >>> unnecessary return statement will never be reached. >>> >> >> Yes you totally have this correctly. >> None of the dozens of comp.theory people could >> ever achieve that level of understanding even >> after three years. That is why I needed to post >> on comp.lang.c. > > Everybody on comp.theory understands this much. No one here ever agreed that when 1 or more instructions of DDD are correctly simulated by HHH that DDD cannot possibly reach its own "return" instruction. Everyone has found one excuse or another to deny this. > PO's plan is that when > he goes elsewhere he can start with noobies and trick them into agreeing > with certain "wordings" by not explaining relevent context for his > questions.  Then he goes back to comp.theory and triumphantly claims > support from elsewhere, proving to himself that comp.theory posters are > all idiots.  :) > > So beware! > >> >>> This conclusion relies on my understanding of what you've said about >>> your code, which I consider to be unreliable. > > Hmm, did PO make it clear that when he says > >    "..DDD correctly simulated by HHH cannot >     possibly REACH its own "return" instruction." > Unless we go one tiny step at a time everyone permanently leaps to a false conclusion and stays there. > he is not talking about whether "DDD halts"?  [I.e. halts when run > directly from main() outside of a simulator.]  No, what he is talking > about is whether the /step-by-step partial simuation/ of DDD performed > by HHH proceeds as far as DDD returning. When 1 or more steps of DDD are correctly simulated by HHH the simulated DDD cannot possibly reach its "return" instruction (final halt state). No one here has agreed to that. Not in several years of coaxing and elaboration. ========== REMAINDER OF ARTICLE TRUNCATED ==========