Behaviour question

[Joona I Palaste]

AFAIK the C standard divides behaviour of different things into four
classes.
1) Defined behaviour. The implementation must do exactly what the
standard says.
2) Implementation-defined behaviour. The implementation must choose some
behaviour, document it, and be consistent about it.
3) Unspecified behaviour. The implementation must pick one of several
possible behaviours, but does not need to be consistent about it.
4) Undefined behaviour. The implementation can do anything it wants to.

Now, let's call the things that cause defined behaviour I, the things
that cause implementation-defined behaviour II, the things that cause
unspecified behaviour III, and the things that cause undefined behaviour
IV.

AFAIK, the compiler is allowed to do any one, or none, of the following:
1) Act as if the C standard defined a strictly set behaviour for I, II,
III and IV.
2) Act as if the C standard defined a strictly set behaviour for I, and
required that the implementation must choose a documented, consistent
behaviour for II, III and IV.
3) Act as if the C standard defined a strictly set behaviour for I,
required that the implementation must choose a documented, consistent
behaviour for II, and required that the implementation must pick one of
several behaviours (but not necessarily consistently) for III and IV.

In other words, this translates to:
1) Act as if everything was defined behaviour.
2) Act as if I was defined behaviour and II, III and IV were
implementation-defined behaviour.
3) Act as if I was defined behaviour, II was implementation-defined
behaviour, and III and IV were unspecified behaviour.

So therefore, if we consider the space of things the standard allows
the implementation to do, defined behaviour is a proper subset of
implementation-defined behaviour, which is a proper subset of
unspecified behaviour, which is a proper subset of undefined behaviour.

For example, painting your house pink is in the set-wise difference
of undefined and unspecified behaviour, and returning 1 from a function
when the program is run once, but returning 2 when it is run again,
without any change in the environment, is in the set-wise difference
of unspecified and implementation-defined behaviour.

Is the above correct? I'd appreciate some sort of in-depth critique.
Thanks.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"How can we possibly use sex to get what we want? Sex IS what we want."
- Dr. Frasier Crane

[Sven Semmler]

Joona I Palaste wrote:

So therefore, if we consider the space of things the standard allows
the implementation to do, defined behaviour is a proper subset of
implementation-defined behaviour, which is a proper subset of
unspecified behaviour, which is a proper subset of undefined behaviour.
No. Defined behaviour is /not a subset/ of implementation defined
behaviour. The behaviour is /either/ (standard-)defined /or/
implementation-defined. If something is (standard-)defined the
implementation is not allowed to define a different behaviour, therefor it
is not part of the implementation-defined domain.

Concerning the other kinds of behaviour, I am not so sure. Nevertheless,
personally I do not write code which uses any not (standard-)defined
behaviour.
For example, painting your house pink is in the set-wise difference
of undefined and unspecified behaviour, and returning 1 from a function
when the program is run once, but returning 2 when it is run again,
without any change in the environment, is in the set-wise difference
of unspecified and implementation-defined behaviour.

Pardon?

/Sven

--
Sven Semmler http://www.semmlerconsulting.com/
GPG Fingerprint: 72CA E26D C2A3 1FEB 7AFC 10EA F769 A9A4 937F 5E67

[Eric Sosman]

Joona I Palaste wrote:

[...]
So therefore, if we consider the space of things the standard allows
the implementation to do, defined behaviour is a proper subset of
implementation-defined behaviour, which is a proper subset of
unspecified behaviour, which is a proper subset of undefined behaviour.

For example, painting your house pink is in the set-wise difference
of undefined and unspecified behaviour, and returning 1 from a function
when the program is run once, but returning 2 when it is run again,
without any change in the environment, is in the set-wise difference
of unspecified and implementation-defined behaviour.

Is the above correct? I'd appreciate some sort of in-depth critique.
Thanks.

I'm not entirely sure I understand where you're heading
with this, so my comments may be wide of the mark. If so,
please be forgiving ...

When you write of "behavior," you seem to concentrate on
the "observed outcome:" painting the house pink, or returning
this or that value. However, an outcome in and of itself is
not (in general) categorizable as defined, implementation-
defined, unspecified, or undefined. One must consider the
stimulus, the circumstances that produce the outcome. The
fact that a function returns 1 on the first invocation and 2
the next could be an example of *any* of your four classes of
behavior:

int defined(void) {
static int x;
return ++x;
}

int implementation_defined(void) {
static int x;
return x += sizeof(short);
}

int unspecified(void) {
static int x;
return x += ("o" == "hello" + 4);
}

int undefined(void) {
auto int x;
return x;
}

I think the attempt to categorize outcomes as "defined"
and so forth is backwards: the Standard actually describes
particular *circumstances* as producing various outcomes.
Some stimuli produce fully-specified outcomes, some produce
completely unrestricted outcomes, some are in between. The
color of your house is not a matter addressed by the Standard,
so we can infer that if a program paints your house pink it
can only be by virtue of invoking undefined behavior: that is,
of allowing circumstances to develop in such a way that the
Standard no longer governs the outcome. But for many other
outcomes it is not possible to reason backwards in this way.

--
Er*********@sun.com