Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 08/05/2025 22:35, Mr Flibble wrote:

On Thu, 08 May 2025 21:01:42 +0100, Richard Heathfield wrote:
 

On 08/05/2025 20:42, olcott wrote:

On 5/8/2025 2:04 PM, Fred. Zwarts wrote:

Op 08.mei.2025 om 19:00 schreef olcott:

<snip>

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

That is counter factual as any fully qualified C programmer will tell
you.

>
As any competent C programmer can tell you, your simulation is driven by
assembly language, not C. Furthermore, neither halt7.c nor x86utm.cpp is
syntactically correct C. Once you fix the syntax errors, that still
leaves you with the undefined behaviour.

 I don't believe the C ISO Standard explictly states that stack overflow is
undefined behaviour

I will go one further and assure you that the standard doesn't mention the word 'stack' at all. My claim of undefined behaviour was not based on stack overflow but on illegal dereferencing.
6.5.3.2(4) says: "If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined."
For the purposes of that paragraph: "Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime."
On the other hand, the standard's definition of undefined behaviour is broad: "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements".
Whether runaway recursion qualifies as nonportable or erroneous is a judgement call. Suffice to say that wise programmers take steps to ensure that their programs don't follow that path.
--
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