Path: ...!news.snarked.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,comp.lang.c
Subject: Re: Every D(D) simulated by H presents non-halting behavior to H ###
Date: Sat, 18 May 2024 12:04:55 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2ajj7$1ct7o$7@i2pn2.org>
References: <v18e32$1vbql$1@dont-email.me> <v1avuv$2lks2$1@dont-email.me>
 <v1b7gl$2ndka$1@dont-email.me> <v1cla9$34iis$1@dont-email.me>
 <v1d2mi$9f72$11@i2pn2.org> <v1di1h$3b2m5$1@dont-email.me>
 <v1dtdv$3dqg4$1@dont-email.me> <v1du2i$3dt7u$1@dont-email.me>
 <v1fetd$3s7jo$1@dont-email.me> <v1ft42$3vdau$2@dont-email.me>
 <-5Gdnf-nQvstC6b7nZ2dnZfqnPadnZ2d@brightview.co.uk>
 <v1gid8$4ilc$1@dont-email.me> <v1h9eu$9faf$1@dont-email.me>
 <v1iqli$nsva$1@dont-email.me> <v1ln3c$vfh$1@news.muc.de>
 <v1s6e6$397iq$2@dont-email.me> <v1slmi$3cjtp$1@dont-email.me>
 <v1t8tt$3gu9t$3@dont-email.me> <v1vc8j$3jmr$1@dont-email.me>
 <v1vsru$7eqc$1@dont-email.me> <v21r4i$otc2$2@dont-email.me>
 <v22k4b$umr4$1@dont-email.me> <v24oah$1h4u3$1@dont-email.me>
 <v256fc$1kais$1@dont-email.me> <v27d05$25ga0$1@dont-email.me>
 <v2838r$29rd7$1@dont-email.me> <v2a8th$2ps09$1@dont-email.me>
 <v2ahqc$2qvr9$1@dont-email.me> <v2aicl$1ct7o$6@i2pn2.org>
 <v2ajd4$2ro09$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 18 May 2024 16:04:55 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1471736"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v2ajd4$2ro09$1@dont-email.me>
Bytes: 5841
Lines: 99

On 5/18/24 12:01 PM, Fred. Zwarts wrote:
> Op 18.mei.2024 om 17:44 schreef Richard Damon:
>> On 5/18/24 11:34 AM, James Kuyper wrote:
>>> On 5/18/24 09:02, Mikko wrote:
>>>> On 2024-05-17 17:14:01 +0000, olcott said:
>>>
>>> I recommend ignoring olcott - nothing good ever comes from paying
>>> attention to him.
>>>
>>>>> On 5/17/2024 5:53 AM, Mikko wrote:
>>>>>> On 2024-05-16 14:50:19 +0000, olcott said:
>>>>>>
>>>>>>> On 5/16/2024 5:48 AM, Mikko wrote:
>>>>>>>> On 2024-05-15 15:24:57 +0000, olcott said:
>>> ...
>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>>>>>> 00 int H(ptr x, ptr x);
>>>>>>>>> 01 int D(ptr x)
>>>>>>>>> 02 {
>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>> 06   return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 int main()
>>>>>>>>> 10 {
>>>>>>>>> 11   H(D,D);
>>>>>>>>> 12   return 0;
>>>>>>>>> 13 }
>>>>>>>>
>>>>>>>> Can you find any compiler that is liberal enough to accept that?
>>>>>>>>
>>>>>>>
>>>>>>> It has been fully operational code under Windows and
>>>>>>> Linux for two years.
>>>>>>
>>>>>> If your compiler does not reject that program it is not a conforming
>>>>>> C compiler. The semantics according to C standard is that a 
>>>>>> diagnostic
>>>>>> message must be given. The standard does not specify what happens if
>>>>>> you execute that program anyway.
>>>>>>
>>>>>
>>>>> It is not nit picky syntax that is the issue here.
>>>>> The SEMANTICS OF THE C PROGRAMMING LANGUAGE SPECIFIES
>>>>>
>>>>> No D simulated correctly by any H of every H/D pair specified
>>>>> by the above template ever reaches its own line 06 and halts.
>>>>
>>>> The standard allows that an program is executed but does not
>>>> specify what happens when an invalid program is executed.
>>>
>>> You've cross-posted this to comp.lang.c after a long-running discussion
>>> solely on comp.theory. Presumably you're doing that because you want
>>> some discussion about what the standard says about this code. For the
>>> sake of those of us who have not been following that discussion on
>>> comp.theory, could you please identify what it is that you think renders
>>> this code invalid? Offhand, I don't see anything wrong with it, but I'm
>>> far more reliable when I say "I see an error" than when I say "I don't
>>> see an error".
>>>
>>>
>>>>> Fully operational software that runs under Widows and Linux
>>>>> proves that the above is true EMPIRICALLY.
>>>>
>>>> No, it does not. As the program is not strictly comforming
>>>> and uses a non-standard extension some implementation may
>>>> execute it differently or refuse to execute.
>>>
>>> Which non-standard extension does it use?
>>
>> I think the issue is the casting of a pointer to function to a pointer 
>> to object, which is one of the grey areas in the standard. (which 
>> occurs in code not shown)
>>
>> It is not specified that such a cast is allowed, but it also isn't 
>> specifically disallowed, it is just omited as a case in the listing of 
>> te possibilities for casting.
>>
>> POSIX requires that certain limited object pointers can be cast to a 
>> function pointer, but that is an extension.
>>
>> Most common architectures will support it as they are both just 
>> "memory addresses" into the same memory space, but that is not 
>> promised by the standard.
> 
> Another issue seems to be that in the declaration of H:
> int H(ptr x, ptr x);
> both parameters have the same name.
> (Olcott is famous for using the same name for different objects.)

He fixes it in some versions, and just shows his carelessness.

I think he naturally does that as H, in this example, is always called 
with the same parameter twice.

That isn't a point I would make a big deal of, he has bigger errors, but 
it does show how he ignores people pointing out errors if he doesn't see 
it himself.