Re: Every D(D) simulated by H presents non-halting behavior to H ###

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