Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem

On 5/11/25 11:32 PM, olcott wrote:

On 5/11/2025 10:11 PM, Keith Thompson wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]

ALL C compilers are required to diagnose ALL syntax errors and ALL
constraint violations.

>
Yes, all conforming C compilers are required to do that.  (Well,
strictly speaking they're only required to issue at least one diagnostic
for any translation unit that violates a syntax rule or constraint.)
>
[...]
>

In my experience, Microsoft's C compiler - although not perfect - is
pretty good at following conformance rules. I'd be surprised to learn
from a competent source that it misses a syntax error.

>
I wouldn't, since few if any C compilers are conforming by default.
>
I've just tried 4 different C compilers (gcc, clang, and tcc
on Ubuntu, MS Visual Studio 2022 on Windows), and none of them
diagnosed a stray semicolon at file scope *by default*.  gcc and
clang can be persuaded to diagnose it.  tcc, as far as I can tell,
cannot; I don't believe it claims to be fully conforming in any mode.
I wasn't able to get MSVS to diagnose it, but there could easily
be an option that I'm missing.
>
If I wanted to prove something in mathematical logic using C code as
a vehicle, I personally would try to use fully standard-conforming C.
I *might* consider using a more lax C-like language, such as the
language accepted by some C compiler in its default mode -- but I'd
need a good reason to do that, and I'd want a rigorous definition
of anything I use that differs from standard C.
>
It's possible that olcott's C-like code has well defined behavior
in the implementation he's using.  If so, I'm not sure there's any
fundamental reason to use something close to C rather than using C
itself in an attempted refutation of some well known mathematical
proof.  (I wouldn't expect either C or something C-like to be a
good vehicle for such a proof.  I don't think C is defined rigorously
enough to be useful for such a task, and any C-like language is even
less so.)
>
olcott will likely use this to claim that I support his views.
He will be wrong.
>
[...]
>

 C code is not as 100% exactingly precise as x86 code.
 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

Which just is not a program, as you have been told, so it is an input that CAN NOT be emulated past the call instruction.

 When one or more steps of DDD are correctly emulated
by any x86 emulator HHH the result is the same as
this code correctly simulated by a C interpreter.
 void DDD()
{
   HHH(DDD);
   return;
}
 I have the "return" statement in there because it
marks a final halt state that is never reached.
 If a computation stops running for any reason
besides reaching a final halt state comp theory
says that this computation never halted. Thus
DDD emulated by HHH never halts.
 People in this forum have been consistently dishonest
about this point for three years.
 

The computation CAN NOT stop for any reason other than reaching the final state.
The fact that the emulation does, just proves that it isn't a correct emulation.
You are just showing your total ignorance of the rules of the system you are talking about, and that you just don't care, so your words are DEAE to anyone with a bit of intelegence, and you are securing your prime seats on the trip to the lake of fire.