Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott 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: References:

<3a92e4a1d264964f8ff5d4de64385a84c7505aaf@i2pn2.org> <2cdf4423d1a8030626738c2dab258688b6c75efc@i2pn2.org>

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: 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: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 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 >>>>> >>>>>> >>>>>> >>>>>> *until H correctly determines that* >>>>>> *its simulated D would never stop running unless aborted* >>>>>> >>>>> 10/13/2022> >>>>>> >>>>> >>>>> But that statement implies, as required that H be a halt decider ========== REMAINDER OF ARTICLE TRUNCATED ==========