XPost: comp.theory, comp.lang.c++   
   From: chris.m.thomasson.1@gmail.com   
      
   On 11/11/2025 12:44 AM, Chris M. Thomasson wrote:   
   > On 11/9/2025 1:59 PM, olcott wrote:   
   >> On 11/8/2025 10:44 PM, Mike Terry wrote:   
   >>> On 09/11/2025 02:08, olcott wrote:   
   >>>> On 11/8/2025 6:30 PM, Mike Terry wrote:   
   >>>>> On 08/11/2025 20:54, olcott wrote:   
   >>>   
   >>> I see you've not changed your behaviour regarding insulting posters   
   >>> by name in the titles of your posts.  Several people have informed   
   >>> you that that is considered bad etiquette for usenet posts.   
   >>>   
   >>> Just for the lols, I've changed the title to insult you! Ho ho ho,   
   >>> what a laugh.   
   >>>   
   >>>   
   >>> Regarding your intensions to continue with your C interpretter   
   >>> devolopment:  that's great, really. Your time is your own, even if   
   >>> others question whether you might be wasting it.   
   >>>   
   >>> I suppose time will tell whether it fails to achieve what you expect   
   >>> it to achieve, as I warned. [..but it seems from your reply (snipped)   
   >>> time will only tell us and not you; that's ok too..]   
   >>>   
   >>>   
   >>> Mike.   
   >>>   
   >>   
   >> *Updated words*   
   >>    Simulating termination analyzer H simulates   
   >>    N statements of D according to the semantics of   
   >>    the C programming language. H does this until it   
   >>    matches a correct non-halting behavior pattern.   
   >>    This pattern conclusively proves that the simulated   
   >>    D cannot possibly reach its own simulated "return"   
   >>    statement final halt state for any value of N.   
   >>   
   >>    Then H aborts its simulation and returns 0 on the   
   >>    basis that that its input D specifies a non-halting   
   >>    sequence of instructions.   
   >>   
   >> This is empirically proven by a C interpreter.   
   >> (Detailed design provided below)   
   >>   
   >> int H(char* P);   
   >>   
   >> int D()   
   >> {   
   >>    int Halt_Status = H(D);   
   >>    if (Halt_Status)   
   >>      HERE: goto HERE;   
   >>    return Halt_Status;   
   >> }   
   >>   
   >> The above is assumed in in test.c   
   >>   
   >> simulate.exe implements a C interpreter.   
   >>   
   >> Command line invocation: simulate test.c   
   >>   
   >> When this interpreter sees the call to H(D) it   
   >> calls itself with the text body of D. I intend   
   >> to make this generic for any named function.   
   >>   
   >> The above proves that N instructions of D simulated   
   >> by H according to the semantics of the C programming   
   >> language cannot possibly reach its own "return"   
   >> statement final halt state.   
   >>   
   >> It is estimated that the adaptation of an existing   
   >> C interpreter should take about one full time week.   
   >> I already found one that can call itself recursively.   
   >>   
   >> The tricky part that might require YACC and LEX is   
   >> parsing the input file to recognize instances of H   
   >> that must be called with text strings of function bodies.   
   >>   
   >   
   > Why even have H at all? Look at the source code itself, do some static   
   > analysis on it. H is pointless here? D can be:   
      
   You can inject something like this:   
      
    > ______________________   
    > int D(int status)   
    > {   
    >      if (status)   
    >      {   
    >          for (;;)   
    >          {   
    >              // lol...   
      
                   ct_yield(...);   
      
    >          }   
    >      }   
    >   
    >      return status;   
    > }   
    > ______________________   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)