Deutsch English Français Italiano |
<v2al4t$2s4fs$3@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> 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:31:25 -0500 Organization: A noiseless patient Spider Lines: 106 Message-ID: <v2al4t$2s4fs$3@dont-email.me> 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 18:31:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="95afb1fc0a4871125108def5044e156a"; logging-data="3019260"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JqsJEXcOo3SV1qvkdh/3Q" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:XjI2LS/q6fX/E4njxwzDJcpLxVg= Content-Language: en-US In-Reply-To: <v2ajd4$2ro09$1@dont-email.me> Bytes: 6075 On 5/18/2024 11:01 AM, 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.) Alan Mackenzie pointed that out yesterday and I could not even see it from the compiler error message. I refactored from working code and got the code to compile and still did not see it. It is common that programmers have complete blind spots once in a while. That is why code review is so important. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer