Re: The D Programming Language
James Kanze wrote:
I don't know quite what different definitions we could be using.
Undefined behavior occurs when the language specification places
no definition on the behavior. I don't know how you can easily
search for it, because it is the absence of a definition. Java
(and most other languages) don't use the term, or even specify
explicitely what they don't specify. So the reponse is rather
the opposite: unless you can find some statement in the language
specification which defines this behavior, it is undefined
behavior.
I was hoping I'd be saved of searching online docs, but now it looks
like I had to, so so be it.
There might be a terminology confusion here, which I'd like to clear
from the beginning:
1. A program "has undefined behavior" = effectively anything could
happen as the result of executing that program. The metaphor with the
demons flying out of one's nose comes to mind. Anything.
2. A program "produces an undefined value" = the program could produce
an unexpected value, while all other values, and that program's
integrity, are not violated.
The two are fundamentally different because in the second case you can
still count on objects being objects etc.; the memory safety of the
program has not been violated. Therefore the program is much easier to
debug.
C++ allows programs with (1). We might also consider that it allows
programs with (2) under the name of "unspecified behavior" or
"implementation-dependent behavior". (There would be a subtle difference
there, but passons.)
My current understanding is that Java programs never exhibit (1), and
might exhibit (2) only on values that can't be read atomically (which
remarkably are never pointers). To find out whether my understanding is
correct, I looked up the language spec, which says after a discussion of
the memory model (see
http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.3):
"Therefore, a data race cannot cause incorrect behavior such as
returning the wrong length for an array."
Later on that page, there is a section "17.7 Non-atomic Treatment of
double and long" that discusses the exact issue we are talking about here.
"Some implementations may find it convenient to divide a single write
action on a 64-bit long or double value into two write actions on
adjacent 32 bit values. For efficiency's sake, this behavior is
implementation specific; Java virtual machines are free to perform
writes to long and double values atomically or in two parts.
For the purposes of the Java programming language memory model, a single
write to a non-volatile long or double value is treated as two separate
writes: one to each 32-bit half. This can result in a situation where a
thread sees the first 32 bits of a 64 bit value from one write, and the
second 32 bits from another write. Writes and reads of volatile long and
double values are always atomic. Writes to and reads of references are
always atomic, regardless of whether they are implemented as 32 or 64
bit values.
VM implementors are encouraged to avoid splitting their 64-bit values
where possible. Programmers are encouraged to declare shared 64-bit
values as volatile or synchronize their programs correctly to avoid
possible complications."
This section can be understood only if we know what a Java program does
once it's read an invalid (say, NaN) value. Will it crash?
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]