Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > What is difference b/w "UNSPECIFIED" and "UNDEFINED" behaviour ?

Reply
Thread Tools

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

 
 
Nitin Bhardwaj
Guest
Posts: n/a
 
      02-19-2004
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)
 
Reply With Quote
 
 
 
 
Spacen Jasset
Guest
Posts: n/a
 
      02-19-2004
"Nitin Bhardwaj" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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.


 
Reply With Quote
 
 
 
 
pete
Guest
Posts: n/a
 
      02-19-2004
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
 
Reply With Quote
 
Spacen Jasset
Guest
Posts: n/a
 
      02-19-2004
> 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.


 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      02-19-2004
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." |
+---------+----------------------------------+-----------------------------+

 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      02-19-2004
In <(E-Mail Removed) > http://www.velocityreviews.com/forums/(E-Mail Removed) (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: (E-Mail Removed)
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      02-19-2004
In <(E-Mail Removed)> Kenneth Brody <(E-Mail Removed)> 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 == 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: (E-Mail Removed)
 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      02-19-2004
Kenneth Brody <(E-Mail Removed)> 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.
 
Reply With Quote
 
Nitin Bhardwaj
Guest
Posts: n/a
 
      02-20-2004
(E-Mail Removed) (Dan Pop) wrote in message news:<c12qnv$f9l$(E-Mail Removed)>...

> 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
 
Reply With Quote
 
Spacen Jasset
Guest
Posts: n/a
 
      02-20-2004
"Nitin Bhardwaj" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Funny behaviour with __future__ and doctest between 2.6 and 3.1 Mattsteel Python 4 01-30-2010 10:25 AM
debugger behaviour different to execution behaviour Andy Chambers Java 1 05-14-2007 09:51 AM
Erractic timeout behaviour with IIS 5.0 and using C# and sqlserver harsh ASP .Net 1 07-23-2006 12:51 PM
operator[] and different behaviour for reading and writing Mark Stijnman C++ 4 05-12-2005 03:52 PM
Difference between bin and obj directories and difference between project references and dll references jakk ASP .Net 4 03-22-2005 09:23 PM



Advertisments