Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!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 11:44:21 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2aicl$1ct7o$6@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 18 May 2024 15:44:21 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1471736"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v2ahqc$2qvr9$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 4982
Lines: 82

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.