Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Fri, 9 May 2025 11:13:34 -0500
Organization: A noiseless patient Spider
Lines: 270
Message-ID: <vvl9je$2rl0l$18@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <vvg8tk$15e69$4@dont-email.me>
 <vvgai8$158tp$6@dont-email.me> <vvgcme$15e69$9@dont-email.me>
 <vvgjdo$18i6e$2@dont-email.me> <vvgkao$18q46$1@dont-email.me>
 <vvgkd7$15i5e$23@dont-email.me> <vvgkum$18q46$3@dont-email.me>
 <vvgleo$15i5e$24@dont-email.me> <vvgov4$1a47o$2@dont-email.me>
 <vvgp8b$15i5e$25@dont-email.me> <vvgpk6$1a47o$4@dont-email.me>
 <vvgpo7$15i5e$26@dont-email.me> <vvgq6o$1acph$1@dont-email.me>
 <vvgqgl$15i5e$27@dont-email.me> <vvgr22$1ag3a$2@dont-email.me>
 <vvgt36$1auqp$2@dont-email.me> <vvgtbe$1b0li$1@dont-email.me>
 <vvguot$1auqp$3@dont-email.me> <vvh0t2$1b939$1@dont-email.me>
 <vvhap5$1hp80$1@dont-email.me> <vvhf20$1ihs9$1@dont-email.me>
 <vvhfnd$1hvei$3@dont-email.me> <vvil99$1ugd5$1@dont-email.me>
 <vvinvp$1vglb$1@dont-email.me>
 <3a92e4a1d264964f8ff5d4de64385a84c7505aaf@i2pn2.org>
 <vvjfrn$28g5i$2@dont-email.me>
 <2cdf4423d1a8030626738c2dab258688b6c75efc@i2pn2.org>
 <vvjnb4$28g5i$10@dont-email.me> <vvkhrq$2m36t$9@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 May 2025 18:13:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b8226b0a928845ead4a9adb4b3b34c7d";
	logging-data="3003413"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX182toQgPsKn9Q3uiCOn7w9k"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:3xXYJvs7ghJRkSWIQj0V5k8bMUo=
In-Reply-To: <vvkhrq$2m36t$9@dont-email.me>
X-Antivirus-Status: Clean
Content-Language: en-US
X-Antivirus: Norton (VPS 250509-2, 5/9/2025), Outbound message

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 
========== REMAINDER OF ARTICLE TRUNCATED ==========