What is difference b/w "UNSPECIFIED" and "UNDEFINED" behaviour ?

[Nitin Bhardwaj]

Well, i'm a relatively new into C( strictly speaking : well i'm a
student and have been doing & studying C programming for the last 4
years).....and also a regular reader of "comp.lang.c"

I don't have a copy of ANSI C89 standard,therefore i had to post this
question:

What is the difference between "unspecified" behaviour & "undefined"
behaviour of some C Code ??

Thank in advance..

(Nitin)

[Spacen Jasset]

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...

Well, i'm a relatively new into C( strictly speaking : well i'm a
student and have been doing & studying C programming for the last 4
years).....and also a regular reader of "comp.lang.c"

I don't have a copy of ANSI C89 standard,therefore i had to post this
question:

It is available to buy quite cheaply online in digital format. At the last
look $18 USD. That is the C99 standard though ofcourse. If you look on the
web, there should be a C9X draft standard floating about.
What is the difference between "unspecified" behaviour & "undefined"
behaviour of some C Code ??

....

I will have a stab at these meanings, but check the other follow-ups. And
read the C9X standard when you have found it on the web.

UNSPECIFIED: Essentially means some thing will happen in particular, but the
standard does not say what that thing will be - and the compiler system does
not have to have the feature documented. For example:
"The order of evaluation of function arguments is UNSPECIFIED" - so the
compiler documentation doesn't have to say in what order they are evaluated.

UNDEFINED: This means that anything whatsoever can happen in this particular
case, which includes, but is not limited to, crashing, corruption, and
potentially OS, or hardware damage(in theory) -- Obviously bad things like
that don't generally happen, but it gives the express notion that
potentially anything can happen -- and of course UNDEFINED behaviour should
be avoided in all C programs.

IMPLEMENTATION-DEFINED: Here is another word, with a defined meaning. It is
like UNSPECIFIED, but it means that the compiler documentation *must*
include information on what will happen in a particular case.

[pete]

Nitin Bhardwaj wrote:

Well, i'm a relatively new into C( strictly speaking : well i'm a
student and have been doing & studying C programming for the last 4
years).....and also a regular reader of "comp.lang.c"

I don't have a copy of ANSI C89 standard,therefore i had to post this
question:

What is the difference between "unspecified" behaviour & "undefined"
behaviour of some C Code ??

The standard says that the output from unspecified.c will be
either 1 2 or 2 1, but it doesn't say which, and it also says
that compiler documentation doesn't have to which either;
Unspecified behavior is when there is a limited choice
of behavior and no documentation is required by the implementaion
to specify which behavior.
/* BEGIN unspecified.c */

#include <stdio.h>

int count(int* counter);

int main(void)
{
int counter = 0;

printf("%d %d\n", count(&counter), count(&counter));
return 0;
}

int count(int* counter)
{
return ++*counter;
}

/* END unspecified.c */

If you would remove the initialzation of counter,
then the behavior would be undefined.
You would have no idea what the program would do.
It could even crash.
Undefined behavior, is when the behavior of the program
is not covered by the rules of C.

--
pete

[Spacen Jasset]

> Nitin Bhardwaj wrote:
....

Unspecified behavior is when there is a limited choice
of behavior and no documentation is required by the implementaion
to specify which behavior. ....Undefined behavior, is when the behavior of the program
is not covered by the rules of C.

Nitin makes an important distinction here that I failed to make between
undefined and unspecified. By using the words "limited choice of
behavior" -- Without those words the two definitions appear to mean similar
things.
I would like to point out that "undefined" programs are potentialy of no
use. i.e. you don't know what they will do. Whereas:-
Programs exhibiting unspecified behavior are valid and will do what you
expect, except where the unspecified behavior may affect the result.

[Kenneth Brody]

Spacen Jasset wrote:
[...]

I would like to point out that "undefined" programs are potentialy of no
use. i.e. you don't know what they will do. Whereas:-
Programs exhibiting unspecified behavior are valid and will do what you
expect, except where the unspecified behavior may affect the result.

Just curious...

If a program invokes undefined behavior, does it mean that the entire
program is "undefined behavior", even if that code is never executed?
Or is it only "undefined behavior" at the time the particular code is
executed (and from that point on)?

For example:

void do_undefined(int *pint)
{
*pint = *pint++;
}

int main(int argc,char *argv[])
{
int i;

for ( i=0 ; i < 10 ; i++ )
{
printf("%d\n",i);
fflush(stdout);
if ( i == 8 )
do_undefined(&i);
}
}

Is this program guaranteed to at least print 0 through 8, or does
the undefined behavior in do_undefined() mean that the program can
do something "undefined" before i reaches 8?

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

[Dan Pop]

In <17**************************@posting.google.com > ni*************@hotmail.com (Nitin Bhardwaj) writes:

Well, i'm a relatively new into C( strictly speaking : well i'm a
student and have been doing & studying C programming for the last 4
years).....and also a regular reader of "comp.lang.c"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don't have a copy of ANSI C89 standard,therefore i had to post this
question:

What is the difference between "unspecified" behaviour & "undefined"
behaviour of some C Code ??

Read the FAQ! As a "regular reader of comp.lang.c" you were supposed to
be well aware of its existence and of your obligation of consulting it
*before* posting anything.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Christopher Benson-Manica]

Kenneth Brody <ke******@spamcop.net> spoke thus:

If a program invokes undefined behavior, does it mean that the entire
program is "undefined behavior", even if that code is never executed?

Someone may correct me, but I believe the answer is "yes":

"[S]ince the Standard imposes no requirements on the behavior of a compiler
faced with an instance of undefined behavior, the compiler can do
absolutely anything." (The FAQ)

Sounds like carte blanche to me.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Dan Pop]

In <40***************@spamcop.net> Kenneth Brody <ke******@spamcop.net> writes:

If a program invokes undefined behavior, does it mean that the entire
program is "undefined behavior", even if that code is never executed?
Or is it only "undefined behavior" at the time the particular code is
executed (and from that point on)?

For example:

void do_undefined(int *pint)
{
*pint = *pint++;
}

int main(int argc,char *argv[])
{
int i;

for ( i=0 ; i < 10 ; i++ )
{
printf("%d\n",i);
fflush(stdout);
if ( i == 8 )
do_undefined(&i);
}
}

Is this program guaranteed to at least print 0 through 8, or does
the undefined behavior in do_undefined() mean that the program can
do something "undefined" before i reaches 8?

Your program is not required to be translated successfully, because of
the

*pint = *pint++;

statement. The more interesting examples are those where the compiler
cannot detect undefined behaviour at translation time:

#include <stdio.h>
#include <stdlib.h>

void foo(int *p, int *q) { *p = *q++; }

int main(int argc, char *argv[])
{
int i;

for (i = 0; i < atoi(argv[1]); i++) {
printf("%d\n", i);
if (i == 8) foo(&i, &i);
}
return 0;
}

This program *may* invoke undefined behaviour in a couple of places,
but whether it does so or not depends exclusively on the way it is
invoked. Therefore, the compiler has no licence to refuse translating it.

At run time, however, if the first program parameter is a number
above 7, you have NO guarantee that this program will print the digits
0 to 8 before something more or less unusual will occur. If the
implementation can determine that the execution path will necessarily
encounter undefined behaviour, all the bets about the program's behaviour
are off. Likewise, if the execution path cannot possibly encounter
undefined behaviour, the program's output must be as specified in the
description of the abstract machine, so this program must work as
expected if its first parameter is a number between INT_MIN and 7.

This is not the *only* possible interpretation of the C standard, but this
is the one preferred in comp.std.c. It is possible to argue that, if the
program's execution is interrupted before foo() is called, the program
doesn't invoke undefined behaviour and, therefore, its output up to that
moment must be the expected one. And, since the program cannot predict
whether its execution will or will not be interrupted before foo() is
called, it cannot assume that undefined behaviour will be ever invoked!

Of course, in practice, nobody bothers detecting undefined behaviour
before it actually happens, so, even if argv[1] is a number above 7 you're
fairly safe if you manage to stop the program execution before foo is
called.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Nitin Bhardwaj]

Da*****@cern.ch (Dan Pop) wrote in message news:<c1**********@sunnews.cern.ch>...

Read the FAQ! As a "regular reader of comp.lang.c" you were supposed to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ be well aware of its existence and of your obligation of consulting it
*before* posting anything.

Dan

Dan,(sorry for offending you,if so) - you guessed it right, i'm well
aware of the FAQ's existence and in fact i am also in possession of a
hard copy( Steve Summit's book )..so i think when i mentioned the
above (highlighted portion), I should not have been redirected towards
the FAQ in the first place :-( . The fact is that the FAQ does not
clear my doubt;therefore i had to post it here !!

Now with the real issue : The FAQ says the following ( Q# 11.33 )

http://www.eskimo.com/~scs/C-faq/q11.33.html

UNSPECIFIED : Unspecified means that an implementation should choose
some behavior, but need not document it.
UNDEFINED : Undefined means that absolutely anything might happen.

I think choosing **some** behaviour ( without documenting it ) means
that **anything** can happen...So are they not the same thing,i.e
isn't UNSPECIFIED behaviour a subset of UNDEFINED...If that is not so,
then on what basis are they defined as distinct behaviours?

- Nitin

[Spacen Jasset]

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17*************************@posting.google.co m...
....

I think choosing **some** behaviour ( without documenting it ) means
that **anything** can happen...So are they not the same thing,i.e
isn't UNSPECIFIED behaviour a subset of UNDEFINED...If that is not so,
then on what basis are they defined as distinct behaviours?

....
I think you are right in a sense. I belive the C standard does give a more
robust definition of unspecified behavior. (I sitll haven't checked though)

If I give an example:

fn(a, b, c);

Here "the order of evaluation of arguments is unspecified." That does not
mean that anything can happen, becuase here we say *what* is unspecified,
and there is only a finite number of options. 3! possibilities in this
case -- the argments are evaluted in some undocumented order.

With this statement, we have given a finite set of possibilities, which is
what I think unspecified means.Whereas undefined, means that what can happen
has not been said (defined), and so anything can happen.

[Kenneth Brody]

Dan Pop wrote:

In <40***************@spamcop.net> Kenneth Brody <ke******@spamcop.net> writes:

If a program invokes undefined behavior, does it mean that the entire
program is "undefined behavior", even if that code is never executed?
Or is it only "undefined behavior" at the time the particular code is
executed (and from that point on)?

For example: [...]Is this program guaranteed to at least print 0 through 8, or does
the undefined behavior in do_undefined() mean that the program can
do something "undefined" before i reaches 8?

Your program is not required to be translated successfully, because of
the

*pint = *pint++;

statement.

So the mere existence of code that invokes undefined behavior causes
the entire program to be considered "undefined behavior", even if that
section of code isn't executed?

[...]

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

[Dan Pop]

In <17*************************@posting.google.com> ni*************@hotmail.com (Nitin Bhardwaj) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<c1**********@sunnews.cern.ch>...

Read the FAQ! As a "regular reader of comp.lang.c" you were supposed to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

be well aware of its existence and of your obligation of consulting it
*before* posting anything.

Dan

Dan,(sorry for offending you,if so) - you guessed it right, i'm well
aware of the FAQ's existence and in fact i am also in possession of a
hard copy( Steve Summit's book )..so i think when i mentioned the
above (highlighted portion), I should not have been redirected towards
the FAQ in the first place :-( . The fact is that the FAQ does not

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^clear my doubt;therefore i had to post it here !! ^^^^^^^^^^^^^^
This is what you should have *explicitly* mentioned in your question,
pointing out the exact part which is not clear enough to you, the way you
did in this post. This way, we knew on what *exactly* to focus our
answers. Otherwise, our answers could be even worse than the text of the
FAQ. Keep in mind that we can only read what you wrote.
Now with the real issue : The FAQ says the following ( Q# 11.33 )

http://www.eskimo.com/~scs/C-faq/q11.33.html

UNSPECIFIED : Unspecified means that an implementation should choose
some behavior, but need not document it.
UNDEFINED : Undefined means that absolutely anything might happen.

I think choosing **some** behaviour ( without documenting it ) means
that **anything** can happen...
Nope. The behaviour chosen by the implementation must be allowed by the
rest of the standard, even if the implementation does not have to
document it. E.g. the evaluation order of the arguments of a function
call is unspecified.
So are they not the same thing,i.e
isn't UNSPECIFIED behaviour a subset of UNDEFINED...
Yes, unspecified certainly is a subset of undefined.
If that is not so,
then on what basis are they defined as distinct behaviours?

As Steve explains, it is only *undefined* behaviour that is completely
unconstrained by the standard.

Unspecified behaviour is practically impossible to avoid in *any*
program producing output. Example:

#include <stdio.h>

int main()
{
printf("Hello world\n");
return 0;
}

The behaviour of this program is unspecified. Possible behaviours:

1. The program displays the message on its controlling terminal (or dumps
it to whatever file stdout is connected).

2. The printf call fails and nothing or only a part of the intended
program output is sent to stdout.

3. stdout is connected to something like a line printer that has run out
of paper and the program hangs.

4. stdout is connected to a nuclear missile base where the arrival of this
message triggers the 3rd World War. So much for the popular belief
that only undefined behaviour can do that... ;-)

However, this program is not allowed to display "Mary had a little lamb".
But, if we remove the #include <stdio.h> line, its behaviour becomes
undefined and this output becomes one of the allowed behaviours.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

"Spacen Jasset" <sp**********@fastmail.fm> writes:

"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17*************************@posting.google.co m...
...

I think choosing **some** behaviour ( without documenting it ) means
that **anything** can happen...So are they not the same thing,i.e
isn't UNSPECIFIED behaviour a subset of UNDEFINED...If that is not so,
then on what basis are they defined as distinct behaviours?

...
I think you are right in a sense. I belive the C standard does give a more
robust definition of unspecified behavior. (I sitll haven't checked though)

C99 3.4.1:
implementation-defined behavior
unspecified behavior where each implementation documents how the
choice is made

C99 3.4.2:
locale-specific behavior
behavior that depends on local conventions of nationality, culture,
and language that each implementation documents

C99 3.4.3:
undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard imposes
no requirements

C99 3.4.4:
unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is chosen
in any instance

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[pete]

Kenneth Brody wrote:

Dan Pop wrote:

In <40***************@spamcop.net> Kenneth Brody <ke******@spamcop.net> writes:

If a program invokes undefined behavior, does it mean that the entire
program is "undefined behavior", even if that code is never executed?
Or is it only "undefined behavior" at the time the particular code is
executed (and from that point on)?

For example: [...]Is this program guaranteed to at least print 0 through 8, or does
the undefined behavior in do_undefined() mean that the program can
do something "undefined" before i reaches 8?

Your program is not required to be translated successfully, because of
the

*pint = *pint++;

statement.

So the mere existence of code that invokes undefined behavior causes
the entire program to be considered "undefined behavior", even if that
section of code isn't executed?

If the undefined code is unconditionally unreachable, then, no.

http://groups.google.com/groups?selm...ws.hananet.net

--
pete

[Nitin Bhardwaj]

>"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

C99 3.4.3:
undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard imposes
no requirements

C99 3.4.4:
unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is chosen
in any instance

So it boils down to the following :

UNSPECIFIED : The *Standard* gives the implementor 'n' choices, out of
which the implementor chooses one but doesn't document which one.....
--- [ I'll do **this** but i won't tell anybody :-)) ...funny isn't it ].

UNDEFINED : The implementor can break into your house, the *Standard*
can't do anything about it;;Then why does the compiler allow such thing(s)
to get compiled in the first place ???

regards

[Joona I Palaste]

Nitin Bhardwaj <ni*************@hotmail.com> scribbled the following:

So it boils down to the following : UNSPECIFIED : The *Standard* gives the implementor 'n' choices, out of
which the implementor chooses one but doesn't document which one.....
--- [ I'll do **this** but i won't tell anybody :-)) ...funny isn't it ]. UNDEFINED : The implementor can break into your house, the *Standard*
can't do anything about it;;Then why does the compiler allow such thing(s)
to get compiled in the first place ???

To allow for implementation-specific optimisations. Also, from a certain
point of view, non-standard functions invoke undefined behaviour,
because the standard does not define anything about them. You wouldn't
want a compiler that only compiled standard functions, would you?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Keep shooting, sooner or later you're bound to hit something."
- Misfire

[Richard Bos]

ni*************@hotmail.com (Nitin Bhardwaj) wrote:

UNDEFINED : The implementor can break into your house, the *Standard*
can't do anything about it;;Then why does the compiler allow such thing(s)
to get compiled in the first place ???

Not all instances of undefined behaviour can be detected beforehand. For
example, some programs invoke undefined behaviour depending on the
contents of a certain file. If you make sure that that file always
contains correct data before running the program, you'll never invoke
UB, so the compiler should still be able to compile it. (Whether it's
wise to write a program this way is another matter, of course; but it is
legal.)

Richard

[nrk]

Nitin Bhardwaj wrote:

"Keith Thompson" <ks***@mib.org> wrote in message news:ln************@nuthaus.mib.org...

C99 3.4.3:
undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard imposes
no requirements

C99 3.4.4:
unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is chosen
in any instance

So it boils down to the following :

UNSPECIFIED : The *Standard* gives the implementor 'n' choices, out of
which the implementor chooses one but doesn't document which one.....

^^^^^^^
That should read *needn't*. The implementor *can* document her choice if so
desired.
--- [ I'll do **this** but i won't tell anybody :-)) ...funny isn't
it ].

Ideally, you shouldn't need to know. However, the standard doesn't prevent
an implementation from documenting its choices (an implementation may even
document behavior that is undefined accdg. to the standard).

-nrk.
UNDEFINED : The implementor can break into your house, the *Standard*
can't do anything about it;;Then why does the compiler allow such thing(s)
to get compiled in the first place ???

regards

--
Remove devnull for email

[Clark Cox]

In article <17**************************@posting.google.com >,
ni*************@hotmail.com (Nitin Bhardwaj) wrote:

"Keith Thompson" <ks***@mib.org> wrote in message news:ln************@nuthaus.mib.org...

C99 3.4.3:
undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard imposes
no requirements

C99 3.4.4:
unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is chosen
in any instance

So it boils down to the following :

UNSPECIFIED : The *Standard* gives the implementor 'n' choices, out of
which the implementor chooses one but doesn't document which one.....

It would be more accurate to say that the implementor "isn't required to
document which one". (i.e. they are free to document it if they want,
but it isn't required of them).
--- [ I'll do **this** but i won't tell anybody :-)) ...funny isn't it ].
Also, the implementor doesn't need to pick the *same* one each time

UNDEFINED : The implementor can break into your house, the *Standard*
can't do anything about it;;Then why does the compiler allow such thing(s)
to get compiled in the first place ???

Because the compiler cannot detect all instances of undefined
behavior at compile time. Take the following example:

int foo(int *p)
{
return p[50];
}

How is the compiler to know wether or not this function invokes
undefined behavior?

It will invoke undefined behavior if p is NULL, or p is not a valid
pointer, or p is a valid pointer, but points to a block of memory that
is not large enough to hold 51 int's.

It will invoke unspecified behavior if p points to a block of memory
that is large enough, but for which the 51's element has not been
initialized or assigned a known value.

[Flash Gordon]

On Mon, 23 Feb 2004 11:59:08 GMT
nrk <ra*********@devnull.verizon.net> wrote:

Nitin Bhardwaj wrote:

"Keith Thompson" <ks***@mib.org> wrote in message

news:ln************@nuthaus.mib.org...

C99 3.4.3:
undefined behavior
behavior, upon use of a nonportable or erroneous program

construct> or of erroneous data, for which this International
Standard imposes> no requirements

C99 3.4.4:
unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is

chosen> in any instance

So it boils down to the following :

UNSPECIFIED : The *Standard* gives the implementor 'n' choices, out
of which the implementor chooses one but doesn't document which
one.....

^^^^^^^
That should read *needn't*. The implementor *can* document her choice
if so desired.

However, the behaviour may vary depending on the preceding or following
code because of the way the optimiser works. For example, if some
parameters to a function are floating point expressions and others are
integers the optimiser might be able to start the FPU evaluating some of
the parameters early whilst the integer ALU is being used for other
things. Or it might be the other way around.

--- [ I'll do **this** but i won't tell anybody :-)) ...funny
isn't it ].

Ideally, you shouldn't need to know. However, the standard doesn't
prevent an implementation from documenting its choices (an
implementation may even document behavior that is undefined accdg. to
the standard).

Compilers for embedded systems often document undefined behaviour.
Specifically, they often document what happens if you do something like
{
(unsigned char *)50 = 1;
}

Since you need to do such things in order to access memory mapped
devices.

UNDEFINED : The implementor can break into your house, the
*Standard* can't do anything about it;;Then why does the compiler
allow such thing(s) to get compiled in the first place ???

See above, also some detecting buffer overruns is not always possible
(or at least, practical) at compiler compile time.
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spam, it is real and I read it.

[Nils Petter Vaskinn]

On Fri, 20 Feb 2004 10:42:23 -0500, Kenneth Brody wrote:

Dan Pop wrote:

Your program is not required to be translated successfully, because of
the

*pint = *pint++;

statement.

So the mere existence of code that invokes undefined behavior causes
the entire program to be considered "undefined behavior", even if that
section of code isn't executed?

[...]

I think that's the implication yes.
But the actual behavior will very often happen to be as you would expect
up until the point you invoke undefined bahavior. (this is good). And some
times it will be as you expect for some time after you invoke undefined
behaviour. (this is bad).

The point is the standard doesn't say how it should behave, your compiler
may detect the undefined behaviour and refuse to compile your program.
Your compiler may make optimizations that assume everything is defined
behaviour, these optimizations may fail and resulting in errors _before_
the actual undefined code is reached. (I can't imagine how a compiler
would generate code to cause this, except for reordering statements for
optimization, which probably won't happen for 'dead code' that can't be
executed.) Or the compiler may very well have defined that behaviour and
all works well.

The point is that the standard doesn't mandate that _this_ particular form
of undefined bahaviour should cause _that_ particular thing, (then it
wouldn't be undefined would it?), if it did compiler makers would have
much less flexibility on how to make their product work.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[Kenneth Brody]

Nils Petter Vaskinn wrote:

On Fri, 20 Feb 2004 10:42:23 -0500, Kenneth Brody wrote: [...]

So the mere existence of code that invokes undefined behavior causes
the entire program to be considered "undefined behavior", even if that
section of code isn't executed?

[...]
I think that's the implication yes.
But the actual behavior will very often happen to be as you would expect
up until the point you invoke undefined bahavior. (this is good). And some
times it will be as you expect for some time after you invoke undefined
behaviour. (this is bad).

The point is the standard doesn't say how it should behave, your compiler [...] The point is that the standard doesn't mandate that _this_ particular form
of undefined bahaviour should cause _that_ particular thing, (then it
wouldn't be undefined would it?), if it did compiler makers would have
much less flexibility on how to make their product work.

I realize that "undefined" means "anything is allowed here". I was just
wondering if it was the _existence_ or the _execution_ of the undefined-
behavior-invoking-code that caused the undefined behavior.

I realize that compiler writers are unlikely to do much more than either
generate some (semi-)valid code, issue a warning, or simply refuse to
compile the particular module. (And I'd be surprised if a compiler did
anything other than the fist choice.) They're not likely to generate code
to reformat the hard drive upon program startup. Nor are they likely to
have any undefined behavior occur prior to the actual execution of the
segment of code.

I was just curious if the standard said the code had to actually be
executed for "undefined behavior" to occur.

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

[Eric Sosman]

Kenneth Brody wrote:

I realize that "undefined" means "anything is allowed here". I was just
wondering if it was the _existence_ or the _execution_ of the undefined-
behavior-invoking-code that caused the undefined behavior.

Both kinds can occur. Examples:

int main(int argc, char **argv) {
return (argc > 1) ? *argv[argc] : 0;
}

This program exhibits U.B. only if invoked with more than one
command-line argument; if invoked with just one argument (the
"program name"), it does nothing wrong. Thus, the U.B. can
occur only at run time unless the implementation can predict
the future.

#define const 666
#include <stdio.h>
int main(void) {
puts ("Goodbye, cruel world!");
return 0;
}

This program exhibits U.B. of a kind that is likely to be
detected at compile time.

/* file1.c */
#include <stdio.h>
extern double trouble;
int main(void) {
printf ("%g\n", trouble);
return 0;
}

/* file2.c */
#include <stdio.h>
int trouble(void) {
return puts("Right here in River City");
}

Neither of these files is incorrect in and of itself, but
the attempt to link them into a single program produces U.B.
that may have its effect before the program is executed.

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

[Keith Thompson]

Kenneth Brody <ke******@spamcop.net> writes:
[...]

I realize that compiler writers are unlikely to do much more than either
generate some (semi-)valid code, issue a warning, or simply refuse to
compile the particular module. (And I'd be surprised if a compiler did
anything other than the fist choice.) They're not likely to generate code
to reformat the hard drive upon program startup.

[...]

Not deliberately, but if the system includes code that's capable of
formatting the hard drive, a program that exhibits undefined behavior
could plausibly invoke it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Dan Pop]

In <40***************@spamcop.net> Kenneth Brody <ke******@spamcop.net> writes:

Dan Pop wrote:

In <40***************@spamcop.net> Kenneth Brody <ke******@spamcop.net> writes:

>If a program invokes undefined behavior, does it mean that the entire
>program is "undefined behavior", even if that code is never executed?
>Or is it only "undefined behavior" at the time the particular code is
>executed (and from that point on)?
>
>For example:[...] >Is this program guaranteed to at least print 0 through 8, or does
>the undefined behavior in do_undefined() mean that the program can
>do something "undefined" before i reaches 8?

Your program is not required to be translated successfully, because of
the

*pint = *pint++;

statement.

So the mere existence of code that invokes undefined behavior causes
the entire program to be considered "undefined behavior", even if that
section of code isn't executed?

Yes. If the compiler gets to compile this line, its behaviour is no
longer constrained by the C standard.

2 NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
^^^^^^^^^^^
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(with the issuance of a diagnostic message).

As I have already explained, things are different for undefined behaviour
that cannot be decided at compile time, but this is not such a case.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dave Thompson]

On Mon, 23 Feb 2004 09:59:06 -0500, Clark Cox <cl*******@mac.com>
wrote:

In article <17**************************@posting.google.com >,
ni*************@hotmail.com (Nitin Bhardwaj) wrote: (re C99 3.4.3 and 3.4.4)

So it boils down to the following : <snip> UNDEFINED : The implementor can break into your house, the *Standard*
can't do anything about it;;Then why does the compiler allow such thing(s)
to get compiled in the first place ???

Because the compiler cannot detect all instances of undefined
behavior at compile time. Take the following example:

int foo(int *p)
{
return p[50];
}

How is the compiler to know wether or not this function invokes
undefined behavior?

It will invoke undefined behavior if p is NULL, or p is not a valid
pointer, or p is a valid pointer, but points to a block of memory that
is not large enough to hold 51 int's.

Not large enough or not correctly (sufficiently) aligned.

Or, technically, where that memory was last stored as another type
(possibly as bytes) creating a representation that is not a valid int
representation -- but there are few if any platforms that actually
have trap representations in integer types, though it is allowed
except for unsigned char.

Or, for completeness sake, the actual object is volatile, but that
qualifier was cast away at some intermediate point.
It will invoke unspecified behavior if p points to a block of memory
that is large enough, but for which the 51's element has not been
initialized or assigned a known value.

Use of an indeterminate (uninitialized) value is also Undefined
Behavior; besides the theoretical possibly of a trap represenation, it
would also be legal and possibly valuable (though costly without
special hardware, which is arguably costly in its own way) for an
implementation to detect and diagnose use of uninitialized memory.

The only Unspecifieds that I can see applying here are:

- p[50] is part of a member of a union when the last store was to a
different member (in practice, a differently typed one) but did not
create a trap representation -- maybe, this one is not crystal clear;
or was derived (without other UB like overflow) from one or more bytes
(or parts) of a representation that includes padding bytes, union
"residue" bytes, or padding bits in a type that allows and uses them;
or multiple representations, or negative zero, if used.

- or for that matter, on the vanishingly few machines that have
(integer) negative zero some (specified) operations may unspecifiedly
produce it instead of positive; but *used as an int value* it gives
the same results as positive, and so mostly doesn't matter.

- p[50] was affected by order of side effects in initialization of an
aggregate variable or compound literal, or of subexpression (operand)
or function argument evaluation; in particular if
int bar (int *p) { return p[50] = 42; }
int quux (int a, int b) { return a; }
.... int x[51] = {0}; ... quux (foo(p), bar(p)) ...
unspecifiedly produces 0 or 42 -- at least (I think) in C90 with
DR087, though not AFAICS explicitly reflected in C99, except probably
in the attempted "formal model" stuff that didn't make it. (And note
this depends on the sequence points on the calls to foo and bar; if
those were just expressions, or macros, you're back to Undefined.)

- p[50] contains a value produced by certain library functions such as
ftell() or time(), converted down if needed; but these are almost
certainly documented even though not mandated by the standard.

- David.Thompson1 at worldnet.att.net