#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

int P(ptr x)
{ H(x, x);
return 1;
}

int main(void)
{ H(P, P);
}

For every H that simulates or executes its input and aborts or does not
abort its input P never reaches its last instruction.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/16/2021 10:10 PM, wij wrote:
> On Wednesday, 17 November 2021 at 11:33:49 UTC+8, olcott wrote:

#include <stdint.h>
#include <stdio.h>
typedef int (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

int P(ptr x)
{ H(x, x);
return 1;
}

int main(void)
{ H(P, P);
}

For every H that simulates or executes its input and aborts or does not
abort its input P never reaches its last instruction.

> I would guess yes, it is specified: BAD, illegal program

It must be compiled as C and the typedef was incorrect.
I can't find a way to specify the "C" calling convention for g++

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/16/2021 8:46 PM, olcott wrote:
> #include <stdint.h>
> #include <stdio.h>
> typedef int (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y); // direct execution of P(P)
>   return 1;
> }
>
> int P(ptr x)
> {
>   H(x, x);
>   return 1;
> }
>
> int main(void)
> {
>   H(P, P);
> }

Stack overflow...

On Wednesday, 17 November 2021 at 05:13:08 UTC, Chris M. Thomasson wrote:
> On 11/16/2021 8:46 PM, olcott wrote:
> > #include <stdint.h>
> > #include <stdio.h>
> > typedef int (*ptr)();
> >
> > int H(ptr x, ptr y)
> > {
> > x(y); // direct execution of P(P)
> > return 1;
> > }
> >
> > int P(ptr x)
> > {
> > H(x, x);
> > return 1;
> > }
> >
> > int main(void)
> > {
> > H(P, P);
> > }
> Stack overflow...

Surely a compiler can optimise this to remove the recursion, and for that matter, remove any functionality at all, as the code has no observable behaviour, as far as I can see (I'd be happy to be corrected on this!).

$DIETY only knows what olcott was trying to show with this code.

On 11/16/21 11:46 PM, olcott wrote:
> On 11/16/2021 10:10 PM, wij wrote:
>> On Wednesday, 17 November 2021 at 11:33:49 UTC+8, olcott wrote:
>
> #include <stdint.h>
> #include <stdio.h>
> typedef int (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y); // direct execution of P(P)
>   return 1;
> }
>
> int P(ptr x)
> {
>   H(x, x);
>   return 1;
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> For every H that simulates or executes its input and aborts or does not
> abort its input P never reaches its last instruction.
>
>> I would guess yes, it is specified: BAD, illegal program
>
> It must be compiled as C and the typedef was incorrect.
> I can't find a way to specify the "C" calling convention for g++
>

Shows you don't understand C++.

Making it 'C' calling convention doesn't change the syntax for the call.

In C++, an empty parameter list specifies a void parameter list, while
in C it specifies tha mostly obsolete concept that this is a
non-prototype declaration that doesn't specify the parameters.

Ultimately the problem is that this runs into the issue that it is
impossible to express in C a function that takes or returns a pointer to
the same type as the function itself is, as that requires self
references in the type definition.

On 11/17/2021 2:28 AM, Mark Bluemel wrote:
> On Wednesday, 17 November 2021 at 05:13:08 UTC, Chris M. Thomasson wrote:
>> On 11/16/2021 8:46 PM, olcott wrote:
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> typedef int (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>> x(y); // direct execution of P(P)
>>> return 1;
>>> }
>>>
>>> int P(ptr x)
>>> {
>>> H(x, x);
>>> return 1;
>>> }
>>>
>>> int main(void)
>>> {
>>> H(P, P);
>>> }
>> Stack overflow...
>
> Surely a compiler can optimise this to remove the recursion, and for that matter, remove any functionality at all, as the code has no observable behaviour, as far as I can see (I'd be happy to be corrected on this!).
>

This is the question:
For every H that simulates or executes its input and aborts or does not
abort its input does any P ever reach its last instruction?

> $DIETY only knows what olcott was trying to show with this code.
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/17/2021 5:53 AM, Richard Damon wrote:
> On 11/16/21 11:46 PM, olcott wrote:
>> On 11/16/2021 10:10 PM, wij wrote:
>>> On Wednesday, 17 November 2021 at 11:33:49 UTC+8, olcott wrote:
>>
>> #include <stdint.h>
>> #include <stdio.h>
>> typedef int (*ptr)();
>>
>> int H(ptr x, ptr y)
>> {
>>    x(y); // direct execution of P(P)
>>    return 1;
>> }
>>
>> int P(ptr x)
>> {
>>    H(x, x);
>>    return 1;
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>>
>> For every H that simulates or executes its input and aborts or does not
>> abort its input P never reaches its last instruction.
>>
>>> I would guess yes, it is specified: BAD, illegal program
>>
>> It must be compiled as C and the typedef was incorrect.
>> I can't find a way to specify the "C" calling convention for g++
>>
>
> Shows you don't understand C++.
>
> Making it 'C' calling convention doesn't change the syntax for the call.
>
> In C++, an empty parameter list specifies a void parameter list, while
> in C it specifies tha mostly obsolete concept that this is a
> non-prototype declaration that doesn't specify the parameters.
>
> Ultimately the problem is that this runs into the issue that it is
> impossible to express in C a function that takes or returns a pointer to
> the same type as the function itself is, as that requires self
> references in the type definition.
>

This code does compile and run correctly.
The only difference from Ben's code is that
void (*ptr)(); was changed to int (*ptr)();

In comp.lang.c On 11/11/2021 2:31 PM, Ben Bacarisse:
transformed my syntax into his syntax

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 17/11/2021 04:46, Wolcott wrote:
> On 11/16/2021 10:10 PM, wij wrote:
>> On Wednesday, 17 November 2021 at 11:33:49 UTC+8, olcott wrote:
>
>
>

#include <stdio.h>

void count(int n)
{ static int d = 1;
printf("n = %d\n", n);
printf("d = %d\n", d);

d++;

if (n > 1)
{
count(n - 1);
}
printf("d = %d\n", d);
} int main()
{ count(5);
return 0;
}

In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>> typedef int (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>> x(y); // direct execution of P(P)
>>> return 1;
>>> }
>
> This code does compile and run correctly.

It might compile as C, but it shouldn't compile as C++, because it's trying
to call an int(*)() with a parameter, even though that function (that the
pointer is pointing to does not take any parameter.)

Perhaps if it were an int(*)(void*) and then you reinterpret-cast the
parameter in order to call it, then it would compile.

As for "runs correctly", I don't see how this "runs correctly". Unless you
mean an infinite recursion that does nothing "runs correctly".

Juha Nieminen <nospam@thanks.invalid> writes:

> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>>> typedef int (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>> x(y); // direct execution of P(P)
>>>> return 1;
>>>> }
>>
>> This code does compile and run correctly.
>
> It might compile as C, but it shouldn't compile as C++, because it's trying
> to call an int(*)() with a parameter, even though that function (that the
> pointer is pointing to does not take any parameter.)

Just as it must not compile in C++, this code must compile in C. The
meaning of empty ()s in a function declaration is different between the
two languages.

When I tidied up the code, I wrote C, not C++, because C has a more
suitable type available.

--
Ben.

On 11/18/2021 12:32 AM, Juha Nieminen wrote:
> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>>> typedef int (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>> x(y); // direct execution of P(P)
>>>> return 1;
>>>> }
>>
>> This code does compile and run correctly.
>
> It might compile as C, but it shouldn't compile as C++, because it's trying
> to call an int(*)() with a parameter, even though that function (that the
> pointer is pointing to does not take any parameter.)
>
> Perhaps if it were an int(*)(void*) and then you reinterpret-cast the
> parameter in order to call it, then it would compile.
>
> As for "runs correctly", I don't see how this "runs correctly". Unless you
> mean an infinite recursion that does nothing "runs correctly".
>

This is the question that I am asking:

Does this program have the specified behavior?
For every H that simulates or executes its input and aborts or does not
abort its input P never reaches its last instruction.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/18/2021 5:15 AM, Ben Bacarisse wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>
>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>>>>> typedef int (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>> x(y); // direct execution of P(P)
>>>>> return 1;
>>>>> }
>>>
>>> This code does compile and run correctly.
>>
>> It might compile as C, but it shouldn't compile as C++, because it's trying
>> to call an int(*)() with a parameter, even though that function (that the
>> pointer is pointing to does not take any parameter.)
>
> Just as it must not compile in C++, this code must compile in C. The
> meaning of empty ()s in a function declaration is different between the
> two languages.
>
> When I tidied up the code, I wrote C, not C++, because C has a more
> suitable type available.
>

You did a really great job.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Mark Bluemel <mark.bluemel@gmail.com> writes:

> On Wednesday, 17 November 2021 at 05:13:08 UTC, Chris M. Thomasson wrote:
>
>> On 11/16/2021 8:46 PM, olcott wrote:
>>
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> typedef int (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>> x(y); // direct execution of P(P)
>>> return 1;
>>> }
>>>
>>> int P(ptr x)
>>> {
>>> H(x, x);
>>> return 1;
>>> }
>>>
>>> int main(void)
>>> {
>>> H(P, P);
>>> }
>>
>> Stack overflow...
>
> Surely a compiler can optimise this to remove the recursion, and
> for that matter, remove any functionality at all, as the code has
> no observable behaviour, as far as I can see (I'd be happy to be
> corrected on this!).

A program that simply does a 'return 0;' from main() does have
observable behavior: it modifies no files (and doesn't perform
any volatile accesses or do any I/O to interactive devices). The
empty set is still a set.

By contrast, a program that sits and does nothing and simply runs
forever does /not/ have observable behavior. The reason is
simple: the predicate condition for what happens with files is
evaluated only at program termination. No termination means no
way to assess observable behavior.

The question of whether the C standard allows (or intends to
allow) the program transformation you describe is a thorny
problem, and not one I'm planning on researching further. But
considering just "observable behavior" in the two cases, ISTM
that the two programs clearly are not identical, because one
does have observable behavior and the other one does not.

On 12/10/21 4:40 AM, Tim Rentsch wrote:
> Mark Bluemel <mark.bluemel@gmail.com> writes:
>
>> On Wednesday, 17 November 2021 at 05:13:08 UTC, Chris M. Thomasson wrote:
>>
>>> On 11/16/2021 8:46 PM, olcott wrote:
>>>
>>>> #include <stdint.h>
>>>> #include <stdio.h>
>>>> typedef int (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>> x(y); // direct execution of P(P)
>>>> return 1;
>>>> }
>>>>
>>>> int P(ptr x)
>>>> {
>>>> H(x, x);
>>>> return 1;
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>> H(P, P);
>>>> }
>>>
>>> Stack overflow...
>>
>> Surely a compiler can optimise this to remove the recursion, and
>> for that matter, remove any functionality at all, as the code has
>> no observable behaviour, as far as I can see (I'd be happy to be
>> corrected on this!).
>
> A program that simply does a 'return 0;' from main() does have
> observable behavior: it modifies no files (and doesn't perform
> any volatile accesses or do any I/O to interactive devices). The
> empty set is still a set.
>
> By contrast, a program that sits and does nothing and simply runs
> forever does /not/ have observable behavior. The reason is
> simple: the predicate condition for what happens with files is
> evaluated only at program termination. No termination means no
> way to assess observable behavior.
>
> The question of whether the C standard allows (or intends to
> allow) the program transformation you describe is a thorny
> problem, and not one I'm planning on researching further. But
> considering just "observable behavior" in the two cases, ISTM
> that the two programs clearly are not identical, because one
> does have observable behavior and the other one does not.
>

I think the key point is that the infinite recursion means the program
exceeds the environment bounds for defined operation and thus the
behavior of the program has become officially 'Undefined Behavior'. Once
the compiler can see that this will happen, it is freed of all restrictions.

Any observable behavior that would happen before the program enters
Undefined Behavior needs to happen, but there is none, so the compiler,
if it is smart enough to recognize the behavior, is totally free to do
what ever it wants with the program.

Richard Damon <Richard@Damon-Family.org> writes:

> On 12/10/21 4:40 AM, Tim Rentsch wrote:
>
>> Mark Bluemel <mark.bluemel@gmail.com> writes:
>>
>>> On Wednesday, 17 November 2021 at 05:13:08 UTC, Chris M. Thomasson wrote:
>>>
>>>> On 11/16/2021 8:46 PM, olcott wrote:
>>>>
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>> typedef int (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>> x(y); // direct execution of P(P)
>>>>> return 1;
>>>>> }
>>>>>
>>>>> int P(ptr x)
>>>>> {
>>>>> H(x, x);
>>>>> return 1;
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>> H(P, P);
>>>>> }
>>>>
>>>> Stack overflow...
>>>
>>> Surely a compiler can optimise this to remove the recursion, and
>>> for that matter, remove any functionality at all, as the code has
>>> no observable behaviour, as far as I can see (I'd be happy to be
>>> corrected on this!).
>>
>> A program that simply does a 'return 0;' from main() does have
>> observable behavior: it modifies no files (and doesn't perform
>> any volatile accesses or do any I/O to interactive devices). The
>> empty set is still a set.
>>
>> By contrast, a program that sits and does nothing and simply runs
>> forever does /not/ have observable behavior. The reason is
>> simple: the predicate condition for what happens with files is
>> evaluated only at program termination. No termination means no
>> way to assess observable behavior.
>>
>> The question of whether the C standard allows (or intends to
>> allow) the program transformation you describe is a thorny
>> problem, and not one I'm planning on researching further. But
>> considering just "observable behavior" in the two cases, ISTM
>> that the two programs clearly are not identical, because one
>> does have observable behavior and the other one does not.
>
> I think the key point is that the infinite recursion means the
> program exceeds the environment bounds for defined operation and
> thus the behavior of the program has become officially 'Undefined
> Behavior'. [...]

This conclusion isn't right. First, the C standard doesn't
mention any such environmental limit. Second, even if it did,
exceeding an environmental limit doesn't make defined behavior
turn into undefined behavior. Consider the following program:

int
main( void ){
int x;
{{{ .. one billion open braces... {{{
x = 0;
}}} .. one billion close braces.. }}}
return x;
}

An implementation is free to reject this program, but if the
program is accepted it has well-defined semantics, which is
to say its behavior is defined, not undefined. And that is
true regardless of what environmental limits the implementation
may have.

In the context of the C standard, the word "behavior" refers to a
specification, not an action. In other words the "behavior" of
a program is what the program /should/ do, not necessarily what the
program /will/ do, if and when it is executed. A program that just
recurses infinitely has "defined behavior" in the sense that the
C standard uses the term.

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Mark Bluemel <mark.bluemel@gmail.com> writes:
>
> > On Wednesday, 17 November 2021 at 05:13:08 UTC, Chris M. Thomasson wrote:
> >
> >> On 11/16/2021 8:46 PM, olcott wrote:
> >>
> >>> #include <stdint.h>
> >>> #include <stdio.h>
> >>> typedef int (*ptr)();
> >>>
> >>> int H(ptr x, ptr y)
> >>> {
> >>> x(y); // direct execution of P(P)
> >>> return 1;
> >>> }
> >>>
> >>> int P(ptr x)
> >>> {
> >>> H(x, x);
> >>> return 1;
> >>> }
> >>>
> >>> int main(void)
> >>> {
> >>> H(P, P);
> >>> }
> >>
> >> Stack overflow...
> >
> > Surely a compiler can optimise this to remove the recursion, and
> > for that matter, remove any functionality at all, as the code has
> > no observable behaviour, as far as I can see (I'd be happy to be
> > corrected on this!).
>
> A program that simply does a 'return 0;' from main() does have
> observable behavior: it modifies no files (and doesn't perform
> any volatile accesses or do any I/O to interactive devices). The
> empty set is still a set.
>
> By contrast, a program that sits and does nothing and simply runs
> forever does /not/ have observable behavior. The reason is
> simple: the predicate condition for what happens with files is
> evaluated only at program termination. No termination means no
> way to assess observable behavior.
>
> The question of whether the C standard allows (or intends to
> allow) the program transformation you describe is a thorny
> problem, and not one I'm planning on researching further. But
> considering just "observable behavior" in the two cases, ISTM
> that the two programs clearly are not identical, because one
> does have observable behavior and the other one does not.

AFAICS currently there is accepted view among theorists that
changing non-terminating behavior into terminating behaviour
is valid program transformation. Concerning C standard
relevant part in N1570 seem to be 5.1.2.3 point 6. IIUC
if program does not terminate on abstract machine clause
about files at program termination is empty: it places no
obligation on implementation. It seems that also clause
about interactive streams places no obligation on
implementation when program performs no I/O. So it seems
that according to N1570 changing non-terminating program
into terminating one is allowed.

At practical level gcc seem to keep infinite loop with empty
body. I can imagine why gcc is doing that...

--
Waldek Hebisch

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> In the context of the C standard, the word "behavior" refers to a
> specification, not an action. In other words the "behavior" of
> a program is what the program /should/ do, not necessarily what the
> program /will/ do, if and when it is executed.
[...]

The standard's definition of "behavior" is "external appearance or
action".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

antispam@math.uni.wroc.pl writes:
[...]
> AFAICS currently there is accepted view among theorists that
> changing non-terminating behavior into terminating behaviour
> is valid program transformation. Concerning C standard
> relevant part in N1570 seem to be 5.1.2.3 point 6. IIUC
> if program does not terminate on abstract machine clause
> about files at program termination is empty: it places no
> obligation on implementation. It seems that also clause
> about interactive streams places no obligation on
> implementation when program performs no I/O. So it seems
> that according to N1570 changing non-terminating program
> into terminating one is allowed.
>
> At practical level gcc seem to keep infinite loop with empty
> body. I can imagine why gcc is doing that...

N1570 6.8.5p6 is relevant:

An iteration statement whose controlling expression is not a
constant expression, that performs no input/output operations, does
not access volatile objects, and performs no synchronization or
atomic operations in its body, controlling expression, or (in the
case of a for statement) its expression-3, may be assumed by the
implementation to terminate.

with a footnote:

This is intended to allow compiler transformations such as removal
of empty loops even when termination cannot be proven.

This was added in C11.

Personally, I dislike it, partly because it's written in terms of what
the implementation may assume rather than the behavior of a program.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

antispam@math.uni.wroc.pl writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Mark Bluemel <mark.bluemel@gmail.com> writes:
>>
>>> On Wednesday, 17 November 2021 at 05:13:08 UTC, Chris M. Thomasson wrote:
>>>
>>>> On 11/16/2021 8:46 PM, olcott wrote:
>>>>
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>> typedef int (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>> x(y); // direct execution of P(P)
>>>>> return 1;
>>>>> }
>>>>>
>>>>> int P(ptr x)
>>>>> {
>>>>> H(x, x);
>>>>> return 1;
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>> H(P, P);
>>>>> }
>>>>
>>>> Stack overflow...
>>>
>>> Surely a compiler can optimise this to remove the recursion, and
>>> for that matter, remove any functionality at all, as the code has
>>> no observable behaviour, as far as I can see (I'd be happy to be
>>> corrected on this!).
>>
>> A program that simply does a 'return 0;' from main() does have
>> observable behavior: it modifies no files (and doesn't perform
>> any volatile accesses or do any I/O to interactive devices). The
>> empty set is still a set.
>>
>> By contrast, a program that sits and does nothing and simply runs
>> forever does /not/ have observable behavior. The reason is
>> simple: the predicate condition for what happens with files is
>> evaluated only at program termination. No termination means no
>> way to assess observable behavior.
>>
>> The question of whether the C standard allows (or intends to
>> allow) the program transformation you describe is a thorny
>> problem, and not one I'm planning on researching further. But
>> considering just "observable behavior" in the two cases, ISTM
>> that the two programs clearly are not identical, because one
>> does have observable behavior and the other one does not.
>
> AFAICS currently there is accepted view among theorists that
> changing non-terminating behavior into terminating behaviour
> is valid program transformation.

The question here concerns only what the C standard does or does
not allow.

> Concerning C standard
> relevant part in N1570 seem to be 5.1.2.3 point 6. IIUC
> if program does not terminate on abstract machine clause
> about files at program termination is empty: it places no
> obligation on implementation.

Changing a program that does not have observable behavior into
one that does have observable behavior is obviously a significant
change.

> It seems that also clause
> about interactive streams places no obligation on
> implementation when program performs no I/O. So it seems
> that according to N1570 changing non-terminating program
> into terminating one is allowed.

A follow-up from Keith Thompson points out N1570 6.8.5p6, which
explicitly allows turning kinds of non-terminating programs into
terminating programs. Since the C standard identifies specific
cases where such a tranformation /is/ allowed, it is reasonable
to infer that they are /not/ allowed in other cases. "The
exception proves the rule, in cases not excepted."

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>
>> In the context of the C standard, the word "behavior" refers to a
>> specification, not an action. In other words the "behavior" of
>> a program is what the program /should/ do, not necessarily what the
>> program /will/ do, if and when it is executed.
>
> [...]
>
> The standard's definition of "behavior" is "external appearance or
> action".

It is. Despite that, in how the C standard uses the term it refers
to a specification for what should happen, not what actually does
happen. A program like this

int
main( void ){
unsigned x = 1;
return x == 0;
}

has defined behavior, whether the program is ever run or not, or
even whether the program is ever compiled. Some text in the C
standard is guilty, to be sure, of some sloppy usage in this
regard, but in context it's clear that "behavior" means a
description or specification of an external appearance or
action, and not an actual appearance or action. For example,
if a program has "undefined behavior", an implementation is
free to do what it chooses. That's a specification of what
appearances or actions are allowed (namely, anything at all),
not a statement of what appearances or actions take place.