Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable

Liste des GroupesRevenir à cl c 
Sujet : Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable
De : rjh (at) *nospam* cpax.org.uk (Richard Heathfield)
Groupes : comp.theory
Date : 08. May 2025, 06:33:33
Autres entêtes
Organisation : Fix this later
Message-ID : <vvhfnd$1hvei$3@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
User-Agent : Mozilla Thunderbird
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.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Date Sujet#  Auteur
25 May 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal