Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Newsgroups: comp.theory
Subject: Re: Formal systems that cannot possibly be incomplete except for
 unknowns and unknowable
Date: Thu, 8 May 2025 17:14:33 +0100
Organization: A noiseless patient Spider
Lines: 111
Message-ID: <vvil99$1ugd5$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <vvall0$o6v5$1@dont-email.me>
 <vvc33h$25atc$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 08 May 2025 18:14:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="69c073830ae6b666c3dcb0619ca095de";
	logging-data="2048421"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19k+R65+EbklplA/I97QhSs8lshac6+HUc="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:JDj8VFVbuHoMJ0DQCwMUe9aYIHs=
In-Reply-To: <vvhfnd$1hvei$3@dont-email.me>
Bytes: 6304

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.