undefined behavior defined

Discussion in 'C Programming' started by E. Robert Tisdale, Jan 11, 2004.

  1. In the context of the comp.lang.c newsgroup,
    the term "undefined behavior" actually refers to
    behavior not defined by the ANSI/ISO C [89]9 standard.
    Specifically, it is *not* true that "anything can happen"
    if your C code invokes "undefined behavior".

    Behavior not defined by the ANSI/ISO C [89]9 standard
    may be defined by some other standard (i.e. POSIX) or
    it may be defined by [the implementation of] your compiler,
    your operating system or your machine architecture.
    There exists *no* combination of the above
    in which behavior is not defined.

    Behavior may be "undocumented" or documentation may be "unpublished".
    Sometimes, this is because of an oversight on the part of
    the respective developers but, more often, documentation
    of non-standard "features" simply isn't offered to the public
    because the developer cannot promise to support the "features".

    There has never been a credible report of
    demons flying up any programmer's nose
    because he [or she] invoked "undefined behavior".
     
    E. Robert Tisdale, Jan 11, 2004
    #1
    1. Advertisements

  2. E. Robert Tisdale

    Jack Klein Guest

    Wrong again, dipstick.

    The term "undefined behavior" is precisely defined in the C standard
    itself, so therefore it has a precise meaning in the C language and
    the comp.lang.c newsgroup.

    Paragraph 3 of section 3.4.3 states:

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

    Notice the key phrase "imposes no requirements". In small words, that
    means that if your program produces undefined behavior, anything at
    all that happens is just as valid or invalid as anything else, as far
    as the standard C language is concerned.
    Of course this as absurd. There are circumstances under which the
    behavior is undefined because it is just plain unknowable and
    unpredictable until the actual instant of execution, each and every
    time the code is executed.

    And of course, there is no such thing as a POSIX standard as far as
    this group is concerned.
    No, but there have been cases of hard disk drive reformatting.
    Jumping to an indeterminate pointer on an IBM XT could well result in
    invoking the ROM hard disk format routine.

    Tell me how defined the behavior of this program is:

    #include <time.h>
    #include <stdio.h>

    int main(void)
    {
    double *dp = (double *)time(0);
    printf("The value is %f\n", *dp);
    return 0;
    }

    Now just what document tells me whether this program will be shut down
    for a memory access violation, a memory alignment fault, a floating
    point hardware exception, or will happen to output some gibberish?
    And what guarantees that the result will be the same if I run the same
    program tomorrow, next week, next month, next year?

    The possible non-standard definitions of what might happen when
    undefined behavior is invoked is just plain irrelevant -- and
    off-topic -- here.
     
    Jack Klein, Jan 11, 2004
    #2
    1. Advertisements

  3. Irrelevant, as nobody claims otherwise.

    OTOH, the often heard claim that if a C program invoked undefined
    behavior, a conforming C implementation would be allowed to make
    demons fly out of the programmer's nose, is definitely true. This
    follows directly from 3.4.3#1.

    Martin
     
    Martin Dickopp, Jan 11, 2004
    #3
  4. There have been multiple credible reports of harddisks being reformatted
    because a programmer invoked "undefined behavior". Actually, upon closer
    examination, _every single case_ of a harddisk being reformatted by a C
    program involved "undefined behavior".
     
    Christian Bau, Jan 11, 2004
    #4
  5. E. Robert Tisdale

    Joe Wright Guest

    Why did you bother to write this? You cannot be that clueless. The
    Standard defines the behaviour of certain program constructs on valid
    data. Anything else is "undefined behaviour".
    No. The demons fly out from your nose. Not credible? If you can't
    believe Kaz, who's left? :)
     
    Joe Wright, Jan 11, 2004
    #5
  6. Wrong. The behavior that led to the harddisk-reformatting might
    instead have been implementation-defined; for example, the
    behavior upon signed integer truncation.

    "I assigned 0xFF to a 'char' and demons flew out of my nose!
    Luckily, I had read the manual and was expecting it."

    --Zak

    -Arthur
     
    Arthur J. O'Dwyer, Jan 11, 2004
    #6
  7. E. Robert Tisdale

    CBFalconer Guest

    You are talking about E.R. Trollsdale here. He has climbed far
    greater heights in the past; this is completely innocuous in
    comparison.
     
    CBFalconer, Jan 11, 2004
    #7
  8. I don't think that it is possible to write a C program
    to reformat a hard disk drive without invoking behavior
    not defined by the ANSI/ISO C[89]9 standard.
     
    E. Robert Tisdale, Jan 11, 2004
    #8
  9. Isn't that exactly what I said above?
    No. The phrase "imposes no requirements" means exactly that.
    Not even that "anything at all that happens
    is just as valid or invalid as anything else".
    It means that what happens is left up to the compiler developer.
    Where is it written that unpredictable behavior is undefined behavior?
    Nonsense!
    The POSIX standard exists independent of
    whether or not it is off-topic in any usenet newsgroup
    unless you are a member of the Flat Earth Society:

    http://www.flat-earth.org/
    I am appalled by your misunderstanding of "undefined behavior".
    How did you know that it could "shut down" due to
    a memory access violation, a memory alignment fault,
    a floating-point hardware exception or output some gibberish?
    Evidently, you are aware that the behavior of this program
    is *well* defined -- it's simply not predictable
    because you don't have easy access to all of the information
    that would be required to predict what will happen.
    But, given that your platform is deterministic,
    it is, in principle, *always* possible to predict
    what this program will do each time that you run it.

    But what I really want to know is,
    "Did demons ever fly up your nose when you ran this program?" ;-)
     
    E. Robert Tisdale, Jan 11, 2004
    #9
  10. E. Robert Tisdale

    CBFalconer Guest

    Very good. Direct contradiction with your own quote above.
    Logic, thy name is Trollsdale.
     
    CBFalconer, Jan 11, 2004
    #10
  11. No, I don't think it's a contradiction. Trollsdale didn't say in the
    above quote that it was possible to reformat a hard disk drive without
    invoking undefined behaviour. All he seemed to have said was that it
    was not possible to make demons fly out of one's nose even with
    invoking undefined behaviour.
    Trollsdale's two statements here don't have anything to do with each
    other, so they don't contradict each other either.
     
    Joona I Palaste, Jan 12, 2004
    #11
  12. :
    [...]
    Where is it written that undefined must be predictable?

    Just because, in general, the "undefined behavior" a given constuct
    produces for version X of compiler Y is "predictable" doesn't mean
    that it has to be. And, given the example provided somewhere else
    which is virtually guaranteed to be "unpredictable", doesn't that
    pretty much shut down your argument?

    Yes, "i = i++" is likely to produce the same result ("i" will either
    contain the original value or its incremented value) in a given version
    of a given compiler doesn't mean that the behavior isn't "undefined".
    The next release may change the result without breaking anything,
    other than pre-broken code.

    However, this is only because the compiler writers don't go out of
    there way to do anything special here. It would be perfectly legal
    for a C compiler to generate code to reformat your hard drive upon
    executing such code. The compiler writers just don't bother to do
    so, that's all.

    [...]
    Well, there's the code that's pretty much guaranteed to not be
    "predictable".

    [...]
    I think the same can be said in reverse.
    Because it could do _anything_, including any of the above, and
    still be perfectly legal according to the Standard.
    Please define it.
    How can something be definable but not predictable? (Unless
    the "definition" includes things like "should the

    [...]
    Not me, personally. That doesn't mean I couldn't write a valid C
    compiler that did such a thing. (Well, "couldn't" in the sense of
    "valid C compiler", and not my ability to come up with a method of
    causing demons to fly out your nose. It's the lack of a Nasal
    Demon Generator, and not the definition of "undefined behavior"
    that is stopping me.) Would an MPEG video of such an action be
    sufficient for you?

    --

    +---------+----------------------------------+-----------------------------+
    | 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, Jan 12, 2004
    #12
  13. In which case, the behavior *would* be well defined.
    I believe you. ;-)
    As evidence? No.
     
    E. Robert Tisdale, Jan 12, 2004
    #13
  14. E. Robert Tisdale

    Fao, Sean Guest

    Stop right here...What is the topic comp.lang.c? Implementations are
    not discussed here and I think you should be able to see why.
     
    Fao, Sean, Jan 12, 2004
    #14
  15. The topic is the meaning of "undefined behavior"
    as defined by the ANSI/ISO C[89]9 standards.
     
    E. Robert Tisdale, Jan 12, 2004
    #15
  16. E. Robert Tisdale

    Default User Guest

    No, the topic is How Dumb Can Trollsdale Be? And we know that is "pretty
    dumb".



    Brian Rodenborn
     
    Default User, Jan 13, 2004
    #16
  17. Yes, and the standards says that it "imposes no requirements". So as
    far as the standard is concerned, any possible definition by other
    standards is irrelevant, and as far as the standard is concerned
    anything could happen. So, what is your point?

    And actually I have seen "anything can happen" from completely
    valid standard constructs. Like shutting down a machine:
    "panic: irrecoverable parity error in memory module 16". In the
    abstract C machine undefined behaviour can indeed lead to anything
    to happen. It is pretty easy to write an abstract C machine where
    i++ + i++; might blow up the (abstract) machine in a random fashion.
    (How do you blow up an abstract machine?) It could still completely
    satisfy the standard.
     
    Dik T. Winter, Jan 13, 2004
    #17
  18. E. Robert Tisdale

    CBFalconer Guest

    This is the first time I have heard Trollsdale categorized as
    "pretty". I think his revisionist instincts towards quotes are
    ugly. Not as in duckling.
     
    CBFalconer, Jan 13, 2004
    #18
  19. #define nasal "memory"
    #define demon "corruption"
    #define fly "halt"
    #define out "and catch fire"
    #define nose "computer"
     
    Nils Petter Vaskinn, Jan 13, 2004
    #19
  20. ....
    Virtually. ;-)

    Regards
     
    Irrwahn Grausewitz, Jan 13, 2004
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.