Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Thu, 8 May 2025 21:04:04 +0200
Organization: A noiseless patient Spider
Lines: 171
Message-ID: <vviv75$222r6$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <vvcgja$1voc$1@news.muc.de>
 <vvd6pf$34l9k$1@dont-email.me> <vvdads$13pc$1@news.muc.de>
 <vvdcld$3arjo$1@dont-email.me> <vvg6r9$15e69$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 08 May 2025 21:04:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="44eddd5626cd6b9959ef6b6ed642c4e0";
	logging-data="2165606"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19deajDofcR3oxYkKXOPa5G"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:nr2lVBEG2/HeS/d88wV8ZpeL9Hg=
In-Reply-To: <vvinvp$1vglb$1@dont-email.me>
Content-Language: nl, en-GB
Bytes: 8642

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.

> 
> 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.

Meaning that it should not abort a halting program, and not skip the 
most important part of its input, where it would see a conditional 
abort, which makes the program halting.
But HHH violates the x86 language by halting when there is no HLT 
instruction.

> 
> 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.
> 
> This means that requiring sum(3,2) to return
> the sum of 5 + 7 is an incorrect requirement.
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========