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

    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)