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

Discussion in 'C Programming' started by Nitin Bhardwaj, Feb 19, 2004.

  1. 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)
     
    Nitin Bhardwaj, Feb 19, 2004
    #1
    1. Advertising

  2. "Nitin Bhardwaj" <> wrote in message
    news:...
    > 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.
     
    Spacen Jasset, Feb 19, 2004
    #2
    1. Advertising

  3. Nitin Bhardwaj

    pete Guest

    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
     
    pete, Feb 19, 2004
    #3
  4. > 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.
     
    Spacen Jasset, Feb 19, 2004
    #4
  5. 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." |
    +---------+----------------------------------+-----------------------------+
     
    Kenneth Brody, Feb 19, 2004
    #5
  6. Nitin Bhardwaj

    Dan Pop Guest

    In <> (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:
     
    Dan Pop, Feb 19, 2004
    #6
  7. Nitin Bhardwaj

    Dan Pop Guest

    In <> Kenneth Brody <> 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:
     
    Dan Pop, Feb 19, 2004
    #7
  8. Kenneth Brody <> 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":

    "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.
     
    Christopher Benson-Manica, Feb 19, 2004
    #8
  9. (Dan Pop) wrote in message news:<c12qnv$f9l$>...

    > 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
     
    Nitin Bhardwaj, Feb 20, 2004
    #9
  10. "Nitin Bhardwaj" <> wrote in message
    news:...
    ....
    > 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.
     
    Spacen Jasset, Feb 20, 2004
    #10
  11. Dan Pop wrote:
    >
    > In <> Kenneth Brody <> 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." |
    +---------+----------------------------------+-----------------------------+
     
    Kenneth Brody, Feb 20, 2004
    #11
  12. Nitin Bhardwaj

    Dan Pop Guest

    In <> (Nitin Bhardwaj) writes:

    > (Dan Pop) wrote in message news:<c12qnv$f9l$>...
    >
    >> 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:
     
    Dan Pop, Feb 20, 2004
    #12
  13. "Spacen Jasset" <> writes:
    > "Nitin Bhardwaj" <> wrote in message
    > news:...
    > ...
    > > 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) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
     
    Keith Thompson, Feb 21, 2004
    #13
  14. Nitin Bhardwaj

    pete Guest

    Kenneth Brody wrote:
    >
    > Dan Pop wrote:
    > >
    > > In <> Kenneth Brody <> 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=9QUx9.838$

    --
    pete
     
    pete, Feb 23, 2004
    #14
  15. Nitin Bhardwaj

    Richard Bos Guest

    (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
     
    Richard Bos, Feb 23, 2004
    #15
  16. >"Keith Thompson" <> wrote in message
    news:...
    >
    > 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
     
    Nitin Bhardwaj, Feb 23, 2004
    #16
  17. Nitin Bhardwaj <> 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 () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Keep shooting, sooner or later you're bound to hit something."
    - Misfire
     
    Joona I Palaste, Feb 23, 2004
    #17
  18. Nitin Bhardwaj

    nrk Guest

    Nitin Bhardwaj wrote:

    >>"Keith Thompson" <> wrote in message

    > news:...
    >>
    >> 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
     
    nrk, Feb 23, 2004
    #18
  19. Nitin Bhardwaj

    Flash Gordon Guest

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

    On Mon, 23 Feb 2004 11:59:08 GMT
    nrk <> wrote:

    > Nitin Bhardwaj wrote:
    >
    > >>"Keith Thompson" <> wrote in message

    > > news:...
    > >>
    > >> 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.
     
    Flash Gordon, Feb 23, 2004
    #19
  20. Nitin Bhardwaj

    Clark Cox Guest

    In article <>,
    (Nitin Bhardwaj) wrote:

    > >"Keith Thompson" <> wrote in message

    > news:...
    > >
    > > 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.
     
    Clark Cox, Feb 23, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jakk
    Replies:
    4
    Views:
    12,393
  2. RoSsIaCrIiLoIA

    undefined behaviour seems wrong and a big error

    RoSsIaCrIiLoIA, Feb 12, 2005, in forum: C Programming
    Replies:
    12
    Views:
    524
    Lawrence Kirby
    Feb 16, 2005
  3. Replies:
    14
    Views:
    603
  4. Rajesh S R

    undefined and unspecified behavior

    Rajesh S R, Mar 17, 2007, in forum: C Programming
    Replies:
    12
    Views:
    468
    Kenneth Brody
    Mar 19, 2007
  5. Tomás Ó hÉilidhe

    Warn about unspecified behaviour

    Tomás Ó hÉilidhe, Jul 23, 2008, in forum: C Programming
    Replies:
    3
    Views:
    248
    CBFalconer
    Jul 24, 2008
Loading...

Share This Page