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

<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, 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: 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: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> 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* >>>>> >>>>> >>>> >>>> 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 ==========