• Re: Can someone please verify the execution trace of this?

    From Richard Damon@21:1/5 to olcott on Sat May 18 18:33:53 2024
    XPost: comp.lang.c++

    On 5/18/24 5:40 PM, olcott wrote:
    People are saying that they have no idea what this code does
    because they do not believe it conforms to c11 or c17.

    typedef int (*ptr)();  // ptr is pointer to int function
    00 int H(ptr x, ptr y);
    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 }

    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);

    *keeps repeating* (unless aborted)

    But since you have defined that H WILL abort, that is irrelevant.

    Line 01:
    Line 02:
    Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 03.

    The key thing to note is that no D correctly simulated by any H of every
    H/D pair specified by the above template ever reaches its own line 06
    and halts.


    Without defining what H is, you can't define what the simulation is.

    You are just showing that you don't understand what you are talking about.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jak@21:1/5 to All on Sun May 19 06:24:04 2024
    XPost: comp.lang.c++

    olcott ha scritto:
    On 5/18/2024 8:12 PM, Sam wrote:
    olcott writes:

    People are saying that they have no idea what this code does
    because they do not believe it conforms to c11 or c17.

    typedef int (*ptr)();  // ptr is pointer to int function
    00 int H(ptr x, ptr y);
    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 }

    This does not conform to any version of C or C++. This looks like a
    weird hybrid of C and BASIC, where each line of code is prepended with
    a numeric line number.


    I added the line numbers so that I could describe the execution
    trace. It compiles under Microsoft with these flags:

    cl  /GS- /std:c11 /c /arch:IA32 Test_Compile.c
    cl  /GS- /std:c17 /c /arch:IA32 Test_Compile.c



    Please don't answer the trolls. He had to cut a part of your post in
    order to justify his useless message.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rosario19@21:1/5 to olcott on Sun May 19 06:25:21 2024
    On Sat, 18 May 2024 16:40:45 -0500, olcott wrote:

    People are saying that they have no idea what this code does
    because they do not believe it conforms to c11 or c17.

    typedef int (*ptr)(); // ptr is pointer to int function
    00 int H(ptr x, ptr y);
    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);

    here you call H(D,D) D is just a pointer, but what is H? if it is a
    ponter for me the program is not definited and has to stop here
    im not one expert of C

    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.

    *Execution Trace*
    Line 11: main() invokes H(D,D);

    *keeps repeating* (unless aborted)
    Line 01:
    Line 02:
    Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 03.

    The key thing to note is that no D correctly simulated by any H of every
    H/D pair specified by the above template ever reaches its own line 06
    and halts.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sun May 19 15:24:27 2024
    XPost: comp.lang.c++

    On 5/19/24 3:00 PM, olcott wrote:
    On 5/19/2024 1:08 PM, Bonita Montero wrote:
    Am 18.05.2024 um 23:40 schrieb olcott:
    People are saying that they have no idea what this code does
    because they do not believe it conforms to c11 or c17.

    typedef int (*ptr)();  // ptr is pointer to int function
    00 int H(ptr x, ptr y);
    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 }

    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);

    *keeps repeating* (unless aborted)
    Line 01:
    Line 02:
    Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 03.

    The key thing to note is that no D correctly simulated by any H of every >>> H/D pair specified by the above template ever reaches its own line 06
    and halts.


    Other people think 30s about this, you think years about that.


    It is the basis for my two decades long primary research into
    termination analysis. People on another forum have written
    hundreds of posts claiming that D correctly simulated by H
    reaches its own line 06 and halts.

    *I have only gotten truthful answers on this forum*


    And I did show an H that can do that.

    When you try to add requirements that outlaw my version, it makes the
    logic that you version uses clearly incorrect, so you are stuck.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Mon May 20 10:10:32 2024
    XPost: comp.lang.c++

    Op 20.mei.2024 om 07:38 schreef olcott:
    On 5/20/2024 12:09 AM, Bonita Montero wrote:
    Am 20.05.2024 um 04:43 schrieb olcott:
    On 5/19/2024 8:52 PM, Bonita Montero wrote:
    Am 19.05.2024 um 21:00 schrieb olcott:
    On 5/19/2024 1:08 PM, Bonita Montero wrote:
    Am 18.05.2024 um 23:40 schrieb olcott:
    People are saying that they have no idea what this code does
    because they do not believe it conforms to c11 or c17.

    typedef int (*ptr)();  // ptr is pointer to int function
    00 int H(ptr x, ptr y);
    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 }

    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);

    *keeps repeating* (unless aborted)
    Line 01:
    Line 02:
    Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>>>
    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own
    line 03.

    The key thing to note is that no D correctly simulated by any H
    of every
    H/D pair specified by the above template ever reaches its own
    line 06
    and halts.


    Other people think 30s about this, you think years about that.


    It is the basis for my two decades long primary research into
    termination analysis. People on another forum have written
    hundreds of posts claiming that D correctly simulated by H
    reaches its own line 06 and halts.

    *I have only gotten truthful answers on this forum*


    That's not research, that's nonsense.


    This is not the forum to show that it is not nonsense this is
    a simple C question that I should not even have to ask except
    for a few people in another forum that consistently lie about
    the answer.

    I have been a professional C++ developer since Y2K. So I already
    know the answer, I just need some competent people in this forum
    to attest to this answer. I met Bjarne Stroustrup back when he
    was going around the country promoting his new language.


    You ask the same questions over and over again for years.
    It's like circling your thoughts before you fall asleep -
    you don't think about whether it really makes sense.


    It would take three people five minutes a piece.
    Then I can go back to the other forum.

    They have been lying about how the above code works
    consistently for two years. I know how it works. I
    learned C back when K & R was the standard.

    Three people take five minutes a piece to confirm the
    that the last sentence is correct.

    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.

    Execution Trace
    Line 11: main() invokes H(D,D);

    keeps repeating (unless aborted)
    Line 01:
    Line 02:
    Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    Simulation invariant:
    D correctly simulated by H cannot possibly reach past its own line 03.

    H must be a pure function
    https://en.wikipedia.org/wiki/Pure_function#

    *THIS ONE SENTENCE NEEDS TO BE CONFIRMED*
    For every H/D pair of the above template D correctly simulated
    by H cannot possibly reach its own final state at line 06 and halt.

    Olcott cannot find a proof for his claim. Now he tries a proof by
    authority. He is looking for persons with some authority to support him.
    But such a proof does not depend on the number and the expertise of
    witnesses, as is common for a juridical proof. In computation theory a
    proof consists of logic steps.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Mueller@21:1/5 to All on Mon May 20 15:14:43 2024
    XPost: comp.lang.c++

    Am 18.05.24 um 23:40 schrieb olcott:
    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.

    There is no recursion.
    H is an undefined reference. There is nothing to simulate.

    And even if H would be defined, the implementation of H might never call
    *x or *y.

    Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

    *Simulation invariant*
    D correctly simulated by H cannot possibly reach past its own line 03.

    So this is proven not to be true in general.


    Marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paavo Helde@21:1/5 to olcott on Mon May 20 18:05:28 2024
    XPost: comp.lang.c++

    On 20.05.2024 17:51, olcott wrote:


    int factorial(int n)
    {
      if (n >= 1)
        return n*factorial(n-1);
      else
        return 1;
    }

    This one is tricky. Depending on the parameter value, implementation capabilities and the optimizer quality it may either calculate something
    (which would even be the correct factorial value, for sufficiently small arguments) or cause an integer overflow or a stack overflow. These may
    or may not terminate the program, depending on the compiler, runtime environment and OS details.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Harnden@21:1/5 to olcott on Mon May 20 19:26:21 2024
    XPost: comp.lang.c++

    On 20/05/2024 18:20, olcott wrote:
    On 5/20/2024 12:15 PM, Bonita Montero wrote:
    Am 20.05.2024 um 18:01 schrieb olcott:
    On 5/20/2024 10:16 AM, Bonita Montero wrote:
    Am 20.05.2024 um 16:47 schrieb olcott:

    It is a simple question about the behavior of C functions.
    This group's purpose is the C/C++ language.

    Your question is generic to most languages and you're
    not asking how to do that in C or how to improve that.
    And you're asking the same thing for years.


    Yes I am very persistent. I keep asking until
    I get an answer.


    After some time you should recognize you're doing circles.


    I am asking a straight forward question that people
    keep ignoring it has nothing to do will my circles:
    Ask until answered stops when answered.


    You haven't improved on: https://xkcd.com/1266/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Tue May 21 00:14:46 2024
    XPost: comp.lang.c++

    Op 20.mei.2024 om 18:07 schreef olcott:
    On 5/20/2024 10:17 AM, Bonita Montero wrote:
    Am 20.05.2024 um 16:51 schrieb olcott:

    Anyone having sufficient knowledge of the semantics
    knows the answer. Likewise for these C functions:

    void Infinite_Recursion(u32 N)
    {
       Infinite_Recursion(N);
    }

    int factorial(int n)
    {
       if (n >= 1)
         return n*factorial(n-1);
       else
         return 1;
    }

    void Infinite_Loop()
    {
       HERE: goto HERE;
    }



    I can't believe you're a professional developer when you repeatedly
    run into the wall with simple questions like this for years.

    I have known the answer from an actual execution trace for years.

    The actual execution trace of the infinite number of H/D pairs?

    Anyone with sufficient knowledge of the semantics of the C language
    knows the answer. *I just need several liars to be put in their place*



    Showing a proof for the claim would help more than finding somebody to
    confirm the claim without evidence.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to olcott on Tue May 21 09:55:21 2024
    XPost: comp.lang.c++

    On 21.05.2024 05:58, olcott wrote:
    [...]

    I cannot provide the definition for H because I am asking about
    the behavior of D simulated by H for the infinite set of H/D pairs.

    H is required to correctly simulate 1 to N steps of D and this
    may or may not involve H simulating itself simulating D in recursive simulation.

    I have two fully operational versions of H that run under Windows
    and Linux. I am not asking about those.

    H uses an x86 emulator to emulate the machine code of D and
    H is capable of emulating itself emulating D.

    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 }

    Correct simulation requires correctly emulating the x86 instructions
    of D in the order specified by the machine code of D and may include correctly emulating the x86 instructions of H in the order specified
    by the machine code of H.

    I need to have experts in these two forums verify that no D correctly simulated by *pure function* H can possibly reach its own final state
    at line 06 and halt in N steps of correct simulation.

    We're not doing your homework for you. Please provide or elaborate
    a rationale or explanation for your claim, thought, or theorem, and
    folks here may be able and willing to support you, or show you any
    possibly existing deficiencies.

    (Fred Zwarts has, with slightly different wording, already given this
    hint to you just 24 hours ago. I notice he just repeated that post.)

    Just ignoring the replies thus far and stupidly repeating your code
    is likely considered pathological behavior and may not be honored by
    the audience.

    If you don't understand that it's probably better to just hold your
    breath until you turn blue instead of repeating your post without
    generating any new insights (on both sides).


    https://en.wikipedia.org/wiki/Pure_function#

    I thought it was categorically impossible then Richard found a loophole
    using static data. This new *pure function* requirement eliminates that loophole.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Tue May 21 09:39:29 2024
    XPost: comp.lang.c++

    Op 21.mei.2024 om 05:58 schreef olcott:
    On 5/20/2024 9:23 PM, Keith Thompson wrote:
    wij <wyniijj5@gmail.com> writes:
    [...]
    typedef int (*ptr)();  // ptr is pointer to int function
    int H(ptr x, ptr y);
    int D(ptr x)
    {
       int Halt_Status = H(x, x);
       if (Halt_Status)
         HERE: goto HERE;
       return Halt_Status;
    }

    int main()
    {
       H(D,D);
       return 0;
    }

    The code above does not compile:

    Yes, it does (as you acknowledge in a later post).

    This:
         typedef int (*ptr)();
    defines "ptr" as an alias for a type that can be described in English
    as "pointer to function returning int".  The empty parentheses
    indicate that the function takes an unspecified but fixed number
    and type(s) of arguments; this is an old-style declaration.

    (The C23 standard, not yet released, changes the semantics of empty
    parentheses, causing the code to be invalid, but let's assume C17.)

    The function H is declared but not defined.  That doesn't prevent
    the code from being *compiled*, but it does prevent it from being
    *linked* to produce an executable program.  Perhaps a definition
    of H has been presented in some other article, but I will not waste
    my time hunting for it.

    Ignoring variadic functions like printf, every function call
    must pass the appropriate number and types of arguments, matching
    the parameters defined by the corresponding function definition.
    (In some cases there can be implicit type conversions, but there
    are no implicit conversions for arguments or parameters of function
    pointer type.)  If a correct *prototype* (a function declaration that
    specifies the types of all parameters) is visible, this is enforced
    at compile time; failing to do so is a *constraint violation*,
    requiring a compile-time diagnostic.  If no such prototype is
    visible, violations of this rule need not be diagnosed, but result
    in *undefined behavior*; the C standard says nothing about what
    the program will do.

    I'll note that the code (declares and) defines the function D,
    but never calls it.  The address of D is passed to H, but without
    a definition of H we can't guess what it does with that address.

    It's possible to rewrite the code to (a) avoid the use of old-style
    function declarations and (b) avoids any undefined behavior --
    but without knowing or being able to guess just what the program
    is supposed to do, I see no point in doing so.

    The main point is this: The function H is declared but never
    defined, so it's impossible to create a running program from this
    code, and impossible to guess what it's intended to do without more
    information.  I will not make any assumptions about how H is meant
    to be defined or consult other posts to find a definition.  I may or
    may not follow this thread to see if any clarifications are posted.

    The code as presented is a valid C *translation unit*, but it is
    not a valid *program*, and it has no behavior.


    *That was a great review for c17 standards compliance*

    I cannot provide the definition for H because I am asking about
    the behavior of D simulated by H for the infinite set of H/D pairs.

    H is required to correctly simulate 1 to N steps of D and this
    may or may not involve H simulating itself simulating D in recursive simulation.

    I have two fully operational versions of H that run under Windows
    and Linux. I am not asking about those.

    H uses an x86 emulator to emulate the machine code of D and
    H is capable of emulating itself emulating D.

    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 }

    Correct simulation requires correctly emulating the x86 instructions
    of D in the order specified by the machine code of D and may include correctly emulating the x86 instructions of H in the order specified
    by the machine code of H.

    I need to have experts in these two forums verify that no D correctly simulated by *pure function* H can possibly reach its own final state
    at line 06 and halt in N steps of correct simulation. https://en.wikipedia.org/wiki/Pure_function#

    Olcott is unable to prove his claim. It seems that he understands,
    (although he does not admit) that a claim without a proof has little
    value. Therefore is looking for experts to do the home work for him.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)