undefined behavior defined

[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".

[Jack Klein]

On Sat, 10 Jan 2004 18:14:04 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote in comp.lang.c:

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".
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.
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.
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.
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".

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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Martin Dickopp]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

There has never been a credible report of
demons flying up any programmer's nose
because he [or she] invoked "undefined behavior".

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

[Christian Bau]

In article <40**************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

There has never been a credible report of
demons flying up any programmer's nose
because he [or she] invoked "undefined behavior".

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".

[Joe Wright]

E. Robert Tisdale wrote:

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".
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".
There has never been a credible report of
demons flying up any programmer's nose
because he [or she] invoked "undefined behavior".

No. The demons fly out from your nose. Not credible? If you can't
believe Kaz, who's left? :-)
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Arthur J. O'Dwyer]

On Sun, 11 Jan 2004, Christian Bau wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

There has never been a credible report of
demons flying up any programmer's nose
because he [or she] invoked "undefined behavior".

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".

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

[CBFalconer]

Joe Wright wrote:

E. Robert Tisdale wrote:

.... snipped garbage ...

Why did you bother to write this? You cannot be that clueless.

You are talking about E.R. Trollsdale here. He has climbed far
greater heights in the past; this is completely innocuous in
comparison.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[E. Robert Tisdale]

Christian Bau wrote:

E. Robert Tisdale wrote:

There has never been a credible report of
demons flying up any programmer's nose
because he [or she] invoked "undefined behavior".

There have been multiple credible reports of hard disks
being reformatted because a programmer invoked "undefined behavior".
Actually, upon closer examination,
_every single case_ of a hard disk being reformatted by a C program
involved "undefined behavior".

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]

Jack Klein wrote:

E. Robert Tisdale wrote:

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".
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"

Isn't that exactly what I said above?
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.
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.

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.

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.

Where is it written that unpredictable behavior is undefined behavior?
And of course, there is no such thing as a POSIX standard
as far as this group is concerned.

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/

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".

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(int argc, char* argv[]) {
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.

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?" ;-)

[CBFalconer]

"E. Robert Tisdale" wrote:

Christian Bau wrote:

E. Robert Tisdale wrote:

There has never been a credible report of
demons flying up any programmer's nose
because he [or she] invoked "undefined behavior".

There have been multiple credible reports of hard disks
being reformatted because a programmer invoked "undefined
behavior". Actually, upon closer examination,
_every single case_ of a hard disk being reformatted by a
C program involved "undefined behavior".

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.

Very good. Direct contradiction with your own quote above.
Logic, thy name is Trollsdale.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Joona I Palaste]

CBFalconer <cb********@yahoo.com> scribbled the following:

"E. Robert Tisdale" wrote:

Christian Bau wrote:

> E. Robert Tisdale wrote:
>>There has never been a credible report of
>>demons flying up any programmer's nose
>>because he [or she] invoked "undefined behavior".
>
> There have been multiple credible reports of hard disks
> being reformatted because a programmer invoked "undefined
> behavior". Actually, upon closer examination,
> _every single case_ of a hard disk being reformatted by a
> C program involved "undefined behavior".
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.

Very good. Direct contradiction with your own quote above.
Logic, thy name is Trollsdale.

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 Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It's not survival of the fattest, it's survival of the fittest."
- Ludvig von Drake

[Kenneth Brody]

"E. Robert Tisdale" wrote:
[...]

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.
Where is it written that unpredictable behavior is undefined behavior?

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.

[...]

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

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

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

[...] I am appalled by your misunderstanding of "undefined behavior".
I think the same can be said in reverse.
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?
Because it could do _anything_, including any of the above, and
still be perfectly legal according to the Standard.
Evidently, you are aware that the behavior of this program
is *well* defined
Please define it.
-- it's simply not predictable
How can something be definable but not predictable? (Unless
the "definition" includes things like "should the

[...] But what I really want to know is,
"Did demons ever fly up your nose when you ran this program?" ;-)

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." |
+---------+----------------------------------+-----------------------------+

[E. Robert Tisdale]

Kenneth Brody wrote:

"E. Robert Tisdale" wrote:

But what I really want to know is,
"Did demons ever fly up your nose when you ran this program?" ;-)

Not me, personally. That doesn't mean I couldn't write a valid C
compiler that did such a thing.

In which case, the behavior *would* be well defined.
(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.)
I believe you. ;-)
Would an MPEG video of such an action be sufficient for you?

As evidence? No.

[Fao, Sean]

E. Robert Tisdale wrote:

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)

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.

[E. Robert Tisdale]

Fao, Sean wrote:

E. Robert Tisdale wrote:

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)

Implementations are not discussed here
and I think you should be able to see why.

The topic is the meaning of "undefined behavior"
as defined by the ANSI/ISO C[89]9 standards.

[Default User]

"E. Robert Tisdale" wrote:

The topic is the meaning of "undefined behavior"
as defined by the ANSI/ISO C[89]9 standards.

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

Brian Rodenborn

[Dik T. Winter]

In article <40************@jpl.nasa.gov> E.**************@jpl.nasa.gov writes:

Fao, Sean wrote:

E. Robert Tisdale wrote:

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)

Implementations are not discussed here
and I think you should be able to see why.

The topic is the meaning of "undefined behavior"
as defined by the ANSI/ISO C[89]9 standards.

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, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[CBFalconer]

Default User wrote:

"E. Robert Tisdale" wrote:

The topic is the meaning of "undefined behavior"
as defined by the ANSI/ISO C[89]9 standards.

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

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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Nils Petter Vaskinn]

On Mon, 12 Jan 2004 11:24:57 -0500, Kenneth Brody wrote:

But what I really want to know is,
"Did demons ever fly up your nose when you ran this program?" ;-)

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?

#define nasal "memory"
#define demon "corruption"
#define fly "halt"
#define out "and catch fire"
#define nose "computer"

--
NPV

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

[Irrwahn Grausewitz]

"Dik T. Winter" <Di********@cwi.nl> wrote:
....

(How do you blow up an abstract machine?)

....
Virtually. ;-)

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html