From: Andrei Alexandrescu (See Website For Email) on
James Kanze wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> 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?
>
> Can the VM avoid crashing, if the OS decides that that is what
> it wants to do?
>
> More to the point, does the fact that a Java program cannot
> crash (IF that is the case) mean that Java has no undefined
> behavior, or is it more or less a specious guarantee, with about
> as much meaning as if C++ added a guarantee that no C++ program
> could make demons fly out of your nose. Do my programs suddenly
> loose all undefined behavior if I set SIGILL, SIGBUS, SIGSEGV
> and SIGFPE to ignore at the start?

You misunderstood my question. I asked "Will it crash?" with hope.

Andrei

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andrei Alexandrescu (See Website For Email) on
Francis Glassborow wrote:
> In article <J9KwII.1LMH(a)beaver.cs.washington.edu>, "Andrei Alexandrescu
> (See Website For Email)" <SeeWebsiteForEmail(a)erdani.org> writes
>> I think it's one thing to have a wrong numeric value and one very
>> different thing to have a program in which all hell breaks looks due to
>> random overwriting of memory.
>
> If the program was for a safety critical task I do not think I would
> distinguish. Well al hell breaks loose might just be better than getting
> a 100 times overdose of X-rays. :-)

I agree with your point, however I hope you'll also agree that a program
with one wrong value is easier to debug than a program in which you have
absolutely no guarantee to go by.

To summarize, I guess I'd say that you have a chance to assert() against
a bad value, but you can't do much if you can't even rely on assert()
working properly.


Andrei


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Gabriel Dos Reis wrote:
> Fortunately, not all compilers out there made the decision to actively
> unsupport abstractions like the Digital Mars compiler.

Name one that returns std::complex values in a register pair.

gcc for the x86 (the C compiler) doesn't even return double _Complex or
long double _Complex in a register pair. (It returns them on the stack.
Strangely, it returns float _Complex in the DX:AX register pair, which
is even worse.)

Furthermore, your ABI quotes are clear that if a type has a non-trivial
constructor (which std::complex has), it cannot be passed/returned in
registers.

And lastly, if a UDT really does have trival constructors and
destructors, DMC++ will return them in a register. In fact, it was the
very first C++ compiler to do so. 15 years later, g++ (for the x86)
still does not return structs of any sort in registers.

For example (I think we can agree that Foo doesn't get any more trivial!):
------------- C++ ------------------
struct Foo { int x; };

Foo bar(int i)
{
Foo f;
f.x = i;
return f;
}
------------- g++ ------------------
_Z3bari:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx
movl 12(%ebp), %eax
movl %eax, (%edx)
movl %edx, %eax
leave
ret $4
----------- DMC++ ------------------
?bar@@YA?AUFoo@@H@Z:
mov EAX,4[ESP]
ret
------------------------------------
g++ is returning f on the stack, DMC++ in register EAX. I don't see a
basis for your statement that DMC++ "unsupports" abstractions compared
with other compilers.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Greg Herlihy on
David Abrahams wrote:
> "Andrei Alexandrescu (See Website For Email)"
> <SeeWebsiteForEmail(a)erdani.org> writes:
>
> > 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.
>
> Seriously?
>
> IME you're at least likely to crash noisily close to the undefined
> behavior. If you make everything defined the program necessarily
> soldiers on until one of your own internal checks is able to notice
> that something went wrong. Or am I missing something?

The idea that "undefined behavior" equates to a program crash is a
popular misconception among C+ programmers, and is one the reasons
undefined behavior is often minimized as a problem in C++ programming.
This argument is really saying that C++'s undefined behavior is not
undefined at all - but instead results in the flawed program's
termination. So by a serendiptious stroke of luck, it turns out that
undefined behavior is the same as the ideal behavior - so how can
undefined behavior be a problem?

And much of the time, the C++ programmer is right: the undefined
behavior does terminate the program - but no credit should go to C++.
Rather it is the OS and the runtime that have filled in where the
Standard has been remiss, by defining otherwise undefined behavior. An
obvious example is the dereferencing of a NULL pointer - the
consequences of which are undefined by the Standard, but defined on
almost every modern architectures as a fatal memory access error. So
the fact that this supposedly "undefined behavior" is in fact very
well-defined on most platforms - is what leads to the common
misconception among C++ programmers that all undefined behavior in the
language leads to the same. But of course that is a very mistaken
conclusion..

And in fact in none of these problematic examples cited in this
discussion, lend any support to the believe that a C++ program would be
any more likely to terminate than the Java program in the same
situation. Certainly non-atomic accesses are likely to be too expensive
to detect on a given hardware, and I'm not familiar with any such
error. Of course the reverse argument could also be made: that C++'s
undefined behavior be no different than that of the Java program, so
C++ is none the worse of for it. But if undefined behavior were so
well-behaved, then why can't the Standard just state that that is the
case?

> I don't have any real experience with Java, but Python generally
> exhibits Java-like behavior, and I don't find it easier to debug than
> C++.

I have found Perl almost trivially easy to debug compared to a C++
program. With C++programming there are two levels of correctness to
worry about: first, the program must behave correctly (that is, have
defined behavior at all times) and, second, this correct behavior must
match the behavior that the programmer wants. A Perl (or Java)
programmer does not have to worry about the first level, the program is
always behaved - in other words, it always does what the programmer
tells it to do. So the only concern left is for the programmer to tell
the program what it should be doing in order so that it can produce the
expected (or "correct") results. So in essence a Perl programmer is
already halfway done writing a program compared against the starting
point of a C++ programmer, and this is before eiher programmer has
written a single line of code (OK, that's an exagerration, but it is a
valid point nonetheless).

Greg


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Bo Persson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> It's very simple. In one case you have a program that preserves its
>> own guarantees (e.g. there's no random overwriting of memory), but
>> which has one numerical value that's invalid; that can't corrupt
>> memory because there's no pointer forging. In the other case you
>> can't count on pretty much anything.
>
> But what if that one value, incorrect and unpredictable, is part of an
> airliner's auto pilot, or a nuclear weapons launch system?

You don't build airliner autopilot systems that blindly depend on any
value computed by a single program. You just don't. The first rule of
airliner design for safety is "assume X fails...", where X is any part
of any system.

And I would hope that nuclear weapons launch system would be done to an
even higher standard.

To do any safety critical system, you approach the problem from both
ends: "how do I make this system failproof?" and "when it fails, how do
I keep flying?"


{ Regarding safety standards of nuclear weapons launch systems -- see
<url: http://en.wikipedia.org/wiki/Davy_Crockett_(nuclear_device)>, "the
device could be fired to a dangerously short range by an inept crew".
;-) -mod/aps }

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]