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: Thu, 8 May 2025 17:50:54 -0500
Organization: A noiseless patient Spider
Lines: 247
Message-ID: <vvjcge$27753$2@dont-email.me>
References: <vv97ft$3fg66$1@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> <vviv75$222r6$1@dont-email.me>
 <vvj1fp$22a62$1@dont-email.me> <vvj2j6$23gk7$1@dont-email.me>
 <as9TP.251456$lZjd.93653@fx05.ams4> <87msbmeo3b.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 May 2025 00:50:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b8226b0a928845ead4a9adb4b3b34c7d";
	logging-data="2333859"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tLmNed6nuhOQSnRoEnuEj"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XNKpd2dZoLakapneekjJ9AUHhD4=
X-Antivirus: Norton (VPS 250508-4, 5/8/2025), Outbound message
X-Antivirus-Status: Clean
In-Reply-To: <87msbmeo3b.fsf@nosuchdomain.example.com>
Content-Language: en-US

On 5/8/2025 5:26 PM, Keith Thompson wrote:
> Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
>> On Thu, 08 May 2025 21:01:42 +0100, Richard Heathfield wrote:
>>
>>> On 08/05/2025 20:42, olcott wrote:
>>>> On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
>>>>> Op 08.mei.2025 om 19:00 schreef olcott:
>>>>>> 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
>>>>>>
>>>>>> <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>
>>>>>
>>>>> And since H does not correctly determine that its simulated D would
>>>>> never stop running unless aborted, it is a vacuous statement and
>>>>> Sipser's agreement does not tell anything.
>>>>>
>>>>>
>>>> That is counter factual as any fully qualified C programmer will tell
>>>> you.
>>>
>>> As any competent C programmer can tell you, your simulation is driven by
>>> assembly language, not C. Furthermore, neither halt7.c nor x86utm.cpp is
>>> syntactically correct C. Once you fix the syntax errors, that still
>>> leaves you with the undefined behaviour.
>>
>> I don't believe the C ISO Standard explictly states that stack overflow is
>> undefined behaviour however even if it did Flibble's Law applies: if a UTM
>> is allowed infinite tape then the simulating halt decider is allowed
>> infinite resources (stack space).
> 
> How is that relevant?  Nobody was talking about stack overflow.
> 
> The standard does say that it does not specify "the size or
========== REMAINDER OF ARTICLE TRUNCATED ==========