Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Fred. Zwarts" 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 18:01:39 +0200 Organization: A noiseless patient Spider Lines: 89 Message-ID: References: <-5Gdnf-nQvstC6b7nZ2dnZfqnPadnZ2d@brightview.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 18 May 2024 18:01:40 +0200 (CEST) Injection-Info: dont-email.me; posting-host="8bac9daaa02dfdb861496f7dd70f3d4f"; logging-data="3006473"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18slxfWlic/wvrl+tGMTOEl" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:JrU4aMlS4E4LBYP/8HDknCTHzPo= Content-Language: en-GB In-Reply-To: Bytes: 5429 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.)