E
E. Robert Tisdale
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".
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".