Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 5/9/2025 4:28 AM, Fred. Zwarts wrote:

Op 09.mei.2025 om 03:55 schreef olcott:

On 5/8/2025 8:18 PM, Richard Damon wrote:

On 5/8/25 7:48 PM, olcott wrote:

On 5/8/2025 6:35 PM, Richard Damon wrote:

On 5/8/25 1:00 PM, olcott wrote:

On 5/8/2025 11:14 AM, Mike Terry wrote:

On 08/05/2025 06:33, Richard Heathfield wrote:

On 08/05/2025 06:22, olcott wrote:

On 5/7/2025 11:09 PM, Richard Heathfield wrote:

On 08/05/2025 02:20, olcott wrote:
>
<snip>
>

Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language

>
Let's take a look.
>
The file is 1373 lines long, but don't worry, because I plan to stop at HHH's first departure from the rules of the C programming language (or at least the first departure I spot).
>
Turn in your songbook if you will to:
>
void CopyMachineCode(u8* source, u8** destination)
{
   u32 size;
   for (size = 0; source[size] != 0xcc; size++)
     ;
   *destination = (u8*) Allocate(size);
   for (u32 N = 0; N < size; N++)
   {
     Output("source[N]: ", source[N]);
     *destination[N] = source[N];
   }
   ((u32*)*destination)[-1] = size;
   Output("CopyMachineCode destination[-1]: ", ((u32*)*destination) [-1]);
   Output("CopyMachineCode destination[-2]: ", ((u32*)*destination) [-2]);
};
>

>
deprecated.

>
It's not just deprecated. It's hopelessly broken.
>
Everybody makes mistakes, and one slip would be all very well, but you make essentially the same mistake --- writing to memory that your program doesn't own --- no fewer than four times in a single function.
>

I'll ignore the syntax error (a null statement at file scope is a rookie error).
>
Instead, let's jump straight to this line:
>
   *destination = (u8*) Allocate(size);
>
On line 79 of my copy of the code, we find:
>
u32* Allocate(u32 size) { return 0; }
>
In C, 0 is a null pointer constant, so Allocate returns a null pointer constant... which is fine as long as you don't try to deref it. So now *destination is NULL.
>
We go on:
>
   for (u32 N = 0; N < size; N++)
   {
     Output("source[N]: ", source[N]);
     *destination[N] = source[N];
   }
>
*destination[N] is our first big problem (we're ignoring syntax errors, remember). destination is a null pointer, so destination[N] derefs a null pointer.
>
That's a fail. 0/10, D-, go away and write it again. And you / dare/ to impugn other people's C knowledge! Crack a book, for pity's sake.
>

>
If you can't even understand what is essentially
an infinite recursive relationship between two functions
except that one function can terminate the other then
you don't have a clue about the essence of my system.

>
If you can't even understand why it's a stupendously bad idea to dereference a null pointer, you have no business trying to teach anyone anything about C.
>
Your code is the work of a programmer so hideously incompetent that 'programmer' is scarcely a fair word to use.
>
When you publish code like that, to even *think* about denigrating other people's C knowledge is the height of arrogant hypocrisy.
>

One problem here is that you don't understand how PO's code works. That's to be expected, and PO's response ought to be to explain it so that you understand.  Instead he goes off on one of his rants, so blamewise it's really down to PO.
>
PO's halt7.c is compiled (it is not linked), then the obj file is fed as input to his x87utm.exe which is a kind of x86 obj code execution environment.  x87utm provides a number of primative calls that halt7.c code can make, such as Allocate(), used to allocate a block of memory for use in halt7.c.  Within halt7.c code calls an Allocate() function, and x86utm intercepts that and performs the function internally, then jumps the calling code in halt7.c over the Allocate call where it continues as normal.  The call never goes to the implementation of Allocate in halt7.c, so the null pointer dereferencing does not actually occur.  There are a whole bunch of similar x86utm primitive operations that work in the same way.
>
PO should have said all that, not me, but it seems he's not interested in genuine communication.
>
Mike.
>
>

>
Thanks for those details, they are correct.
I try to stay focused on the key essence gist
of the issue and never delve down into the weeds.
>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
The key gist of the issue (no weeds involved)
is that HHH emulated DD according to the rules
of the x86 language

>
Excpet, as you have admitted, your DD isn't a program (just a C funciton), and thus not a proper input for a halt decider, which by definiton must be a program.
>
Your C function can't be a program, as you have specifically said that the function, and only the funciton is the input, and programs must include in them all their code, so since the code of HHH isn't included in DD or the input representing it, it isn't a program, and thus not a proper input
>

>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     *until H correctly determines that*
     *its simulated D would never stop running unless aborted*
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>

>
But that statement implies, as required that H be a halt decider and D to be a proper input to one, neither of which are satisfied, as you have admitte
>

When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.

>
But it doesn't, as it doesn't correctly follow the behavior of the x86 language, as that requires HHH to follow the call instruction, which it can not do as the required (and accepted by your) condition that the decider is a pure function, which means it can only look at its input, which does not include the code which the call points to.
>

>
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.

>
Right, and a halt decider is required to (try to) compute the mapping from the input (which needs to be the representation of a program) to the results of running that program (since that is the DEFINITION of Halt Deciding).
>

>
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.

>
Right, just as HHH trying to claim that its answer is based on the fact that it can't reach the end of its simulation of the input isn't the correct requirement for HHH.
>

>
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
>

>
Right, which is Halting, since that behavior is DEFINED to be the behavior of running the program the input represents.
>

>
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
>
Its input specifies that it calls HHH(DD) in recursive
emulation. THIS CANNOT BE IGNORED.
>

>
No it doesn't, it calls HHH, which does what it does. Since your decider HHH is defined to abort and return 0, so is the HHH that DD calls, since it was built from that machine.
>
What we can not ignore is that HHH has a definition, and HHH needs to interprete the call in DD by that definition, not you LIE that HHH is just a correct simulator, since it isn't.
>
Sorry, you are the one that is choosing to ignore the input and replace it with somethng it isn't, becaue you don't understand that you did define it when you created your HHH to abort and return 0.

>
void DDD()
{
   HHH(DDD);
   return;
}
>
_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]
>
For every HHH that can possibly exist at machine address
000015d2 that correctly emulates 1 or more x86 instructions
of DDD (the exact machine code bytes specified above) no
correctly emulated DDD ever reaches their own "return"
instruction.
>
This may simply be too difficult for most everyone here.
Instead of simply saying they they don't understand the
x86 language they try to deflect away from this subject
to try to hide their own ignorance.

 

Nobody disagreed with it, we all see that HHH fails to reach the 'return', because it prematurely aborts

 *That remains counter-factual because this is true*

 void DDD()
{
   HHH(DDD);
   return;
}
 When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.