Re: Every sufficiently competent C programmer knows --- Semantic Property of Finite String

On 3/13/25 11:55 PM, olcott wrote:

On 3/13/2025 10:03 PM, Richard Damon wrote:

On 3/13/25 9:48 PM, olcott wrote:

On 3/13/2025 4:21 PM, Richard Heathfield wrote:

On 13/03/2025 20:48, dbush wrote:

On 3/13/2025 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

>
NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

>
The direct execution of DDD

>
is proven to be different than the behavior of DDD emulated by HHH
according to the semantics of the x86 language.

>
Which is weird, considering that a simulator should produce the same
behaviour.
>
>

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC PROPERTY OF
THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort.
>

>
Replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD) cannot possibly
reach its own final state no matter what HHH
does.
>
Replacing the code of HHH1 with an unconditional simulator and subsequently running HHH1(DD) does reach its
own final state.
>
If someone was not a liar they would say that
these are different computations.
>

>
Only because one changes the code that DD runs and one doesn't

>
It hardly matters. Either his emulation faithfully and correctly establishes and reports (for EVERY program anyone cares to feed it) the actual halting behaviour exhibited by the program it's emulating, or it doesn't.
>

>
_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

>
Not a program, and can not be correctly emulated beyond address 0000217A as it goes outside the input.
>

 In other words you are stupidly trying
to get away with saying that it is impossible
for one C function to call another C function.
 

Not at all, just that for a C function to call another C function that other C function must be included as part of the Program that the first is defined in.
C functions are not programs, but programs can be built from C functions,
All you are doing is showing your lack of fundamental knowledge of what you are talking about, and that you "logic" is based on a fraud of redefining fundamental terms of art.
Your problem is you keep on talking about determining if a given program will halt, when what you have isn't a program.
That is like asking what is the frequency of a square?