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

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]
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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer