Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Can someone please verify the execution trace of this?
Date: Mon, 20 May 2024 22:58:41 -0500
Organization: A noiseless patient Spider
Lines: 122
Message-ID: <v2h65i$e0lf$1@dont-email.me>
References: <v2b78t$2vima$1@dont-email.me>
 <v2df79$3ghfd$1@raubtier-asyl.eternal-september.org>
 <v2di7v$3gujt$1@dont-email.me>
 <v2eada$3p6sk$1@raubtier-asyl.eternal-september.org>
 <v2edbr$3pl2i$1@dont-email.me>
 <eaa0ef93ca03f744edc4fbcf6e79fc730805cce9.camel@gmail.com>
 <87v837kinv.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 21 May 2024 05:58:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2f5f52f96f067406075e702eab09af4a";
	logging-data="459439"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ZW+tyYXr0wf7rCXND5DaS"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4geMMF8fWKHSdVMFMdHmBgwfWl4=
Content-Language: en-US
In-Reply-To: <87v837kinv.fsf@nosuchdomain.example.com>
Bytes: 5999

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#

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


-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer