Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: =?UTF-8?Q?Re=3A_Flibble=E2=80=99s_Leap=3A_Why_Behavioral_Divergence?=
 =?UTF-8?Q?_Implies_a_Type_Distinction_in_the_Halting_Problem?=
Date: Sun, 11 May 2025 22:32:14 -0500
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <vvrq3u$sjai$6@dont-email.me>
References: <vv1UP.77894$JJT6.54808@fx16.ams4> <vvqd4u$g8a1$1@dont-email.me>
 <7N2UP.527443$wBt6.464256@fx15.ams4> <vvqfgq$gmmk$1@dont-email.me>
 <os3UP.670056$BFJ.223954@fx13.ams4> <vvqgpt$gmmk$4@dont-email.me>
 <aG3UP.366972$wBVe.321504@fx06.ams4>
 <39947848bf73be52ee6fbbeb6d0d929009dfec8e@i2pn2.org>
 <fR8UP.92502$o31.50010@fx04.ams4>
 <fb3915123ad5c4703b92df902c37267fce2c4812@i2pn2.org>
 <vvrhk6$nejb$2@dont-email.me> <vvrhtj$nnmf$1@dont-email.me>
 <43f0f4158610d859516ba3e0115a8a2b8bd7630b@i2pn2.org>
 <vvrl9h$o2ab$6@dont-email.me> <vvrmso$nt1l$2@dont-email.me>
 <87frha4j5w.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 12 May 2025 05:32:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="15cac720ddbb61c7f6586fe023932af8";
	logging-data="937298"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+ar2TjxK3h6qA9Rw6CXMpj"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:D+3CzG3k+HxcdVs9KytY81FECYQ=
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message
In-Reply-To: <87frha4j5w.fsf@nosuchdomain.example.com>
Content-Language: en-US

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