Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!nntp.comgw.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Thu, 8 May 2025 22:26:55 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <39fd7f30194076f71af0ba9009f92a7a87cfaf2a@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvg7uu$158tp$4@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 9 May 2025 02:27:15 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3737689"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <vvjnb4$28g5i$10@dont-email.me>

On 5/8/25 9:55 PM, olcott wrote:
> 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
========== REMAINDER OF ARTICLE TRUNCATED ==========