XPost: comp.theory, comp.lang.c++   
   From: chris.m.thomasson.1@gmail.com   
      
   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:   
   ______________________   
   int D(int status)   
   {   
        if (status)   
        {   
            for (;;)   
            {   
                // lol...   
            }   
        }   
      
        return status;   
   }   
   ______________________   
      
   right?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)