An interesting quote on Java and C++

An interesting quote on Java and C++

[Nasser]

I thought the Ada folks would be like to read these words, from this
white paper:

http://www.sun.com/sparc/whitepapers/wp96-043.html

"Java was designed as closely to C++ as possible in order to make the
system more understandable"

No, what do the Ada people got to say about that? You can NOT
argue with white papers !

:)

Nasser

Re: An interesting quote on Java and C++

[Samuel Mize]

Nasser, Abbasi wrote:
> No, what do the Ada people got to say about that? You can NOT
> argue with white papers !

I try never to argue with inanimate objects.

Sam Mize

Re: An interesting quote on Java and C++

[Robert Munck]

On 3 Sep 1997 15:30:25 GMT, "Joachim Schroeer" <schroeer@amst.co.at>
wrote:

>Possibly the Java designers never heard of Ada, ...

Heck, they never heard of (UCSD) Pascal.


>What can you expect by languages, that are "invented" by one or two
>'Gurus'?

I have trouble with that, given the examples of Pascal,
Modula, and AED. Maybe you put "Gurus" in quotes to indicate
an awareness of the difference between the hacker-type Unix/EMACS/C
expert and the truly wise, deep understanding of a Wirth or Ross.
There is a lot to be said for the uniformity of a language developed
by a single person from a single paradigm.

Bob Munck
Mill Creek Systems LC

Re: An interesting quote on Java and C++

[Joachim Schroeer]

Robert Munck <munck@mindspring.com> wrote in article
<3410a460.158341309@news.mindspring.com>...
> On 3 Sep 1997 15:30:25 GMT, "Joachim Schroeer" <schroeer@amst.co.at>
> wrote:
> 
> >Possibly the Java designers never heard of Ada, ...
> 
> Heck, they never heard of (UCSD) Pascal.
> 
> 
> >What can you expect by languages, that are "invented" by one or two
> >'Gurus'?
> 
> I have trouble with that, given the examples of Pascal,
> Modula, and AED. Maybe you put "Gurus" in quotes to indicate
> an awareness of the difference between the hacker-type Unix/EMACS/C
> expert and the truly wise, deep understanding of a Wirth or Ross.
> There is a lot to be said for the uniformity of a language developed
> by a single person from a single paradigm.
> 
> Bob Munck
> Mill Creek Systems LC
> 
> 

Ok, I agree, Pascal is the second best teaching language.

  J. Schroeer

Re: An interesting quote on Java and C++

[Robert Dewar]

Bob Munck says

<<I have trouble with that, given the examples of Pascal,
Modula, and AED. Maybe you put "Gurus" in quotes to indicate
an awareness of the difference between the hacker-type Unix/EMACS/C
expert and the truly wise, deep understanding of a Wirth or Ross.
There is a lot to be said for the uniformity of a language developed
by a single person from a single paradigm.>>

The trouble is that these days, no one person is a sufficient expert in
enough areas to build a comprehensive language that deals with a wide
range of problems. For example, key features of Ada are its very carefully
planned numerics model, and its language interfacing capability. The former
was developed with the help of experts in numeric issues, the latter with
the help of experts in the target languages (for example, the COBOL interface
was designed by people who know COBOL well).

This kind of cooperative effort is really a necessity for the development
of a comprehensive programming language.

Re: An interesting quote on Java and C++

[Shmuel (Seymour J.) Metz]

Robert Munck wrote:
> 
> On 3 Sep 1997 15:30:25 GMT, "Joachim Schroeer" <schroeer@amst.co.at>
> wrote:
> 
> >Possibly the Java designers never heard of Ada, ...
> 
> Heck, they never heard of (UCSD) Pascal.

I guess that they didn't mind their P (Systems) and Qs. ;-)

> >What can you expect by languages, that are "invented" by one or two
> >'Gurus'?
> 
> I have trouble with that, given the examples of Pascal,
> Modula, and AED. Maybe you put "Gurus" in quotes to indicate
> an awareness of the difference between the hacker-type Unix/EMACS/C
> expert and the truly wise, deep understanding of a Wirth or Ross.
> There is a lot to be said for the uniformity of a language developed
> by a single person from a single paradigm.

Well, since you mentioned Pascal, are you familiar with the issue of
conformant array parameters? The fact that all labels are integers? (One
of the worst features of Algol 60 was that it *allowed* integer labels,
but at least it didn't require them.) The hash it made of bit strings,
due to confusing "sets" with "sets of small integers"? The I/O model? 
IMHO the quotes around "guru" were earned.

I can think of languages designed by a singl individual that I respect,
but Wirth/Pascal isn't it.

> Bob Munck
> Mill Creek Systems LC

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: An interesting quote on Java and C++

[Robert A Duff]

In article <01bcb881$915526a0$d7000064@sim01.amst.co.at>,
Joachim Schroeer <schroeer@amst.co.at> wrote:
>Possibly the Java designers never heard of Ada, otherwise they did not have
>to invent a new language.

Surely you're not saying that Ada (as is) meets the goals of Java?

>Stroustrup said, that a reason why they developed C++ was, "we
>did not want to program in C". There are other ways to prevent that ...

Indeed.

- Bob

Re: An interesting quote on Java and C++

[Robert Munck]

On Mon, 8 Sep 1997 19:35:29 GMT, bobduff@world.std.com (Robert A Duff)
wrote:
>Surely you're not saying that Ada (as is) meets the goals of Java?
>

I'm not aware of a document that lays out the goals
of the development of Java.  Is there one?  If so,
how does fail to match the goals of Ada (as documented
at great length from Strawman on)?

The only document I've seen about Java goals was a 
rambling white paper from its creator, the gist of
which was that Java meets his preferences and
idiosyncracies.

Bob Munck
Mill Creek Systems LC

Re: An interesting quote on Java and C++

[Robert A Duff]

In article <34157a82.81185415@news.mindspring.com>,
Robert Munck <munck@acm.org> wrote:
>On Mon, 8 Sep 1997 19:35:29 GMT, bobduff@world.std.com (Robert A Duff)
>wrote:
>>Surely you're not saying that Ada (as is) meets the goals of Java?
>
>I'm not aware of a document that lays out the goals
>of the development of Java.  Is there one?

Beats me.  But it's clear from the Java language documents that two
goals of Java are (1) avoid security flaws, and (2) portability at the
cost of efficiency.

Ada meets neither of those goals.  (1) Ada allows dangling pointers and
so forth, and (2) Ada's arithmetic model favors efficiency over
portability.

Of course, Java doesn't meet Ada's goals, either.  For example, the
various run-time checks that Java defines are the minimal needed to
avoid security flaws, and provide absolute portability -- they make no
attempt to catch plain old bugs.  Whereas Ada's run-time checks are
helpful in catching bugs, but don't prevent security violations, and
aren't portable.  Consider, for example, that if X+Y overflows, Java
gives the wrong answer, but always the same answer on all targets.
Whereas Ada raises an exception on overflow, but it doesn't define
exactly when overflow happens on different targets.  Consider also that
Ada allows range constraints, which can help catch bugs, but provide no
particular security benefit -- so Java takes the C attitude there
(although more portable than C); Java can't say "type T is range
1..10;".

>...If so,
>how does fail to match the goals of Ada (as documented
>at great length from Strawman on)?

Not sure what you mean here.  Java doesn't meet Ada's "strawman" goals,
but of course it doesn't try to.  It has different goals.

- Bob

Re: An interesting quote on Java and C++

[Robert Munck]

On Wed, 10 Sep 1997 01:41:22 GMT, bobduff@world.std.com (Robert A
Duff) wrote:

>...  But it's clear from the Java language documents that two
>goals of Java are (1) avoid security flaws, and (2) portability
>at the cost of efficiency.
>
>Ada meets neither of those goals.

And Java does?

I know little about language design for high-security systems,
so I'll leavel #1 for others.  On #2, it seems to me that Ada
has more effort invested in portability than any other language.
Little things like the Validation Suite.  Given that Ada95 can
be compiled to the JVM with the Intermetrics compiler, Ada must
be at least as portable as Java.  I guess that the part of #2
that Ada doesn't meet is "at the cost of efficiency."


>Consider, for example, that if X+Y overflows, Java
>gives the wrong answer, but always the same answer on all targets.

Not currently true, and I'd be willing to bet that it never
will be.  Java has horrible portability problems and they're
getting worse as JIT compilers begin to be used.  Why do you
think Sun is pushing so hard on "100% Pure Java(TM)?" They
know that the only prayer they have of any level of
portability is having all of the JVM implementations come
from one source.

In fact, there seems to be a race between the number of
portability flaws and the number of security flaws in Java.


>...  Java doesn't meet Ada's "strawman" goals,
>but of course it doesn't try to.  It has different goals.

Ok, which of Ada's goals, which Java doesn't even try
to meet, are undesirable for any language?  Code readibility?
Architecture consistency? The ability to write safety-
critical code?

Let's face it, the main goal of Java is to keep Sun
in business.

Bob Munck
Mill Creek Systems LC

Re: An interesting quote on Java and C++

[Robert Dewar]

<<>...  But it's clear from the Java language documents that two
>goals of Java are (1) avoid security flaws, and (2) portability
>at the cost of efficiency.
>
>Ada meets neither of those goals.>>



be careful not to compare the reality of Ada with the Sun (and other) hype
on Java. In the current state of things, Java is nowhere NEAR as portable
as Ada, it is almost the normal case that an applet of any complexity
written on one platform is likely not to work on another platform.

As a further indication of the gap between reality and hype, I am corresponding
with a student in Europe who is looking at portability of IEEE floating-point
between compilers for the same language. He wrote to me that "Ada is doing
very well, things seem to be extremly portable between one implementation
and another ........" but  "Java seems a complete mess, I can't get any
of my IEEE fpt examples to port between Java implementations."

And this from a language that supposedly requires IEEE (although this
requirement is the subject of controversy in the ISO standards committee).

Of course you can say, well that's because the implementations are decrepit,
just wait and see, but then we are back to talking about implementatins
and not languages.

As for security, this is a matter of implementation, not the language.
Indeed, there are all kinds of Java restrictions that must be adhered
to for secure applet delivery that are not enforced by Java itself.
And of coruse if you use an Ada->JVM system, then by definition this
has the same level of security, since the security is implemented at
the JVM level, not at the Java level.

Re: An interesting quote on Java and C++

[Robert A Duff]

In article <dewar.873989964@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
><<>...  But it's clear from the Java language documents that two
>>goals of Java are (1) avoid security flaws, and (2) portability
>>at the cost of efficiency.
>>
>>Ada meets neither of those goals.>>
>
>be careful not to compare the reality of Ada with the Sun (and other) hype
>on Java. In the current state of things, Java is nowhere NEAR as portable
>as Ada, it is almost the normal case that an applet of any complexity
>written on one platform is likely not to work on another platform.

OK, OK, everybody's beating me up about Java's supposed goals.  I must
admit I was wrong as far as practise goes.  I was talking about the
language *definitions*: Ada's language definition allows all kinds of
non-portable stuff, whereas Java's language definition allows extremely
little implementation-definedness.

But I admit that this is theory, and not practise.  In practise,
compiler bugs, and deliberate language modifications by compiler
writers, can both damage portability.  (I'd say that happens for both
languages, by the way.)

My claim is just that if all implementations of Ada and Java obeyed
their language definitions, then Java would be more portable than Ada.
And I admit that you can counter with, "But that's irrelevant --
implementations of Java do *not* obey the Java standard."  (And there
are interesting non-technical (marketting) reasons for compiler writers
to modify the Java language!)  I also admit that "the Java standard" is
perhaps a bogus term, since the standard changes rather often.

>As a further indication of the gap between reality and hype, I am corresponding
>with a student in Europe who is looking at portability of IEEE floating-point
>between compilers for the same language. He wrote to me that "Ada is doing
>very well, things seem to be extremly portable between one implementation
>and another ........" but  "Java seems a complete mess, I can't get any
>of my IEEE fpt examples to port between Java implementations."

Interesting.

>And this from a language that supposedly requires IEEE (although this
>requirement is the subject of controversy in the ISO standards committee).

Also interesting.

How about integers?  The Java standard nails down integers pretty
precisely (exactly 8, 16, 32, and 64-bit arithmetic, with wraparound on
overflow).  Does anybody know whether Java implementations obey this?
Are there any Java implementations on machines where the word size would
make this inconvenient?

>Of course you can say, well that's because the implementations are decrepit,
>just wait and see, but then we are back to talking about implementatins
>and not languages.

I'd say that's backwards.  I argued that the Java *language* is
portable, whereas you and others argue (correctly) that, in practise,
Java *implementations* cause nonportability.

I certainly don't believe the "just wait and see" part.  For
money-making reasons, Java implementations will diverge, I would guess!

>As for security, this is a matter of implementation, not the language.

I disagree.  A correct implementation of Ada allows dangling pointers,
whereas a correct implementation of Java does not.

>Indeed, there are all kinds of Java restrictions that must be adhered
>to for secure applet delivery that are not enforced by Java itself.
>And of coruse if you use an Ada->JVM system, then by definition this
>has the same level of security, since the security is implemented at
>the JVM level, not at the Java level.

No, the Java *language* disallows dangling pointers -- not the JVM.
Yes, I agree you can write Ada implementations that have the same level
of security.

By the way, one case in which the Ada standard nails things down more
precisely than the Java standard is in the area of tasking
(e.g. scheduling of tasks).  But both languages fail to nail this down
completely -- because it's not feasible.

- Bob

Re: An interesting quote on Java and C++

[Shmuel (Seymour J.) Metz]

Robert A Duff wrote:
> 
> How about integers?  The Java standard nails down integers pretty
> precisely (exactly 8, 16, 32, and 64-bit arithmetic, with wraparound on
> overflow).  Does anybody know whether Java implementations obey this?
> Are there any Java implementations on machines where the word size would
> make this inconvenient?

I don't know whether there are any Java implimentations for them, but
the 
definitions of integers in Java would definitely be awkard for the old
Burroughs (now Unisys), GE/Honeywell (now BULL) and Univac (now Unisys);
not only are the word sizes of 36 and 48 bits not powers of 2, but some
of
those machines use ones-complement arithmetic (end-around carry.) I
assume 
that the old CDC machines are not an issue; otherwise they would have
the 
same problems.

Ada, of course, takes a much less machine-dependent definition of the 
world; you define the precision of your variables in terms of the 
application, not in terms of the word size of your computer or virtual 
machine.
 
> - Bob

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: An interesting quote on Java and C++

[Robert A Duff]

In article <34218E68.63D5@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>Ada, of course, takes a much less machine-dependent definition of the 
>world; you define the precision of your variables in terms of the 
>application, not in terms of the word size of your computer or virtual 
>machine.

This is basically good, but it still bothers me that:

    type T is range 0..2_000_000_000;
    X, Y: T := T'Last;
    Z: T := (X + Y) / 2;

will typically behave differently on a 32-bit machine than on a 36-bit
machine.

- Bob

Re: An interesting quote on Java and C++

[Robert Dewar]

<<This is basically good, but it still bothers me that:

    type T is range 0..2_000_000_000;
    X, Y: T := T'Last;
    Z: T := (X + Y) / 2;

will typically behave differently on a 32-bit machine than on a 36-bit
machine.>>

True, this program fragment is non-deterministic, it may raise constraint
error, or it may give the right answer (no other possibilities are allowed).
The decision in Ada not to make such constraint checking canonical was
taken quite deliberately, on the grounds that it would have very significant
efficiency effects.

Since Java is interpreted anyway, at least in the original conception,
it has taken a more casual attitude to efficiency, and the fact that
arithmetic is canonical in Java, if taken seriously, would indeed have
very significant effects on efficiency.

For example, consider a more interesting example than Bob's one (since
there really aren't many 36-bit machines left in wide use).

   A,B,C : Float;
   ...
   A := A * B / C;

Let's assume we are talking IEEE short-form here (Java of course is a
complete catastrphone efficiency-wise on non-IEEE machines such as the
Dec Alpha (*) or the IBM mainframe), but let's not even worry about
that for a moment.

Instead consider the case where A*B is out of range of Float. If we insist
on canonical overflow in this situation, then we will badly harm efficiency
on the x86, which feels like doing all arithmetic in IEEE extended. Ada
quite deliberately in this case (by defining Float as an unconstrained type)
not only allows the intermediate value to overflow, but even the value stored
in A is allowed to be out of range if it is "correct".

Yes, this messes up the language a bit, and yes, this potentially causes
some portability problems, but we are willing to take these minor negatives
in return for a potentially VERY significant gain in efficiency of floating-
point.

Note incidentally that the requirement for IEEE floating-point arithmetic
is controversial, and is under active "discussion" by the ISO Java committee.

(*) thrown in deliberately! Most people, and certainly most DEC sales people,
would think of the DEC Alpha as an IEEE machine. However, the hardware
departs significantly from IEEE in the some areas, including the handling
of denormals, and if you want true IEEE semantics, then you get a huge
slowdown because of software fiddling.

In practice, poeple settle on the Alpha for this slight departure from
IEEE, just as they do on the SGI R10000, which "cheats" in a similar
manner (I should say that both instances of cheating are all about
trying to increase fpt efficiency in the normal case).

Now in languages with no fpt model (C, C++, Fortran, PL/1, Algol-68, Pascal,
Eiffel, ... it is a very long list), there is no problem, you can perfectly
well map to the expected efficient hardware execution mode on both these
machines.

Even in Ada, which has a very definite FPT model, this model has been
very carefuly chosen to balance maximum utility with the ability to
accomodate typical reasonabole floating-point systems, including both
these examples.

The decision in Java, if taken literally to follow IEEE precisely, is a
MAJOR problem on these two architectures, and in practice, the Java
implementations on such machines just ignore the fine points of the rules.

The decision to exactly follow IEEE rules by Sun was one of the following

a) deliberately taken on the grounds that sacrificing efficiency (by as
much as a decimal order of magnitude) was worth the guaranteed 100%
portability.

b) deliberately taken to give Sun a competitive advantage over other
work station manufacturers who don't implement IEEE 100%

c) casually taken without realizing the consequences

I do not know which of a) b) or c) applies.

Re: An interesting quote on Java and C++

[Robert Dewar]

Robert A Duff wrote:
>
> How about integers?  The Java standard nails down integers pretty
> precisely (exactly 8, 16, 32, and 64-bit arithmetic, with wraparound on
> overflow).  Does anybody know whether Java implementations obey this?
> Are there any Java implementations on machines where the word size would
> make this inconvenient?

Note that in Ada, wrap around (modular) types *do* have completely portable
semantics, although in practice people will choose types that match thei
hardware, and efficiency may not be completely portable (the same effect
you see in Java, where clearly 8,16,32,64 are picked not because the world
is full of situations where the domain model requires such types, but because
that's what Sun could implement efficiently.

Re: An interesting quote on Java and C++

[Robert A Duff]

In article <dewar.874759791@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Note that in Ada, wrap around (modular) types *do* have completely portable
>semantics, although in practice people will choose types that match thei
>hardware, ...

Not quite true.  3.5.4(27) allows special treatment of one's comp
machines.  (And there's an AI that worries about what the heck that
paragraph means.)  This is again the "efficiency over portability" way.

Note that modular types are not just about modular arithmetic -- they
also support bit-wise logical operations.  On a one's complement
machine, you still want to be able to have all-ones as a bit pattern, if
you're using these things as bit patterns, even though it's
arithmetically equal to zero.

- Bob

Re: An interesting quote on Java and C++

[Robert Dewar]

Robert Duff says

<<> How about integers?  The Java standard nails down integers pretty
> precisely (exactly 8, 16, 32, and 64-bit arithmetic, with wraparound on
> overflow).  Does anybody know whether Java implementations obey this?
> Are there any Java implementations on machines where the word size would
> make this inconvenient?>>

Yes, of course, the wrap around rules assume twos complement arithmetic
and are a major menace on 1-s complement machines.

Early on, when we were designing Ada 9X, the folks at Unisys, one of the
last companies to make 1-s complement machines on a big scale, got hold
of an early version of the proposed standard which allowed only 
2s complement models for modular integers.

I got a call from a huge gang of people at Unisys, including some quite
high up people, expressing dismay at the fact that the new standard
might be incompatible with their hardware (Unisys by the way has
made quite a commitment to Ada over the years, they did a multi-million
deal with Alsys to acquire and port the Alsys technology to their own
back end code generators).

As it turns out, the final Ada-95 (somewhat unwisely in my view, it seems
a gratuitous feature) allows any modulus, so the mod 2**k-1 arithmetic
required for clean wrap around in the 1-s complement case is supported
(thoughy of course in practice every one uses mod 2**k types which will
indeed look horrid on a 1's complement machine). I do not know if Unisys
has made a similar call to the Java folks, or if they still make those
1's complement machines!

Final note: the history of arbitrary moduli is interesting. One mission
of the design team was to follow the recommendations of the URG as far
as possible, and turn these uniformity recommendations into requirements
where possible. For example the (ratther silly) RM requirement that

21   In an implementation, the range of Integer shall include the range
-2**15+1 .. +2**15-1.


derives from this. Why rather silly? Well the actual URG implementaion
recomends 32 bits, but this was perceived as too fierce for a requirement
(no doubt partly because certain persons were interested in 24-bit integers
on the Patriot :-) and that's probably right, 32-bits would have been too
fierce, so it is better as a recommendation. So what hapened here was the
idea of the requirement remained, but the parametrization is gratuitous
(there is no serious possibility of someone choosing less than 16-bits
for Integer anyway).

Anyhow, back to modular types. The URG had been given a design paper
that recommended arbitrary modular types, but it had overwhelmingly
rejected this as unnecessarily complex, and recommended that only
2**K modular types be supported.

Unfortunately, due to a procedural glitch, the design team picked up
the original rejected design paper, and thought it was a URG recommendation,
so in it went, and to the surprise of me and others, survived the pruning
process which removed many frills.

Of course if you find the non-binary modular stuff useful (I wonder how
much it is used outside ACVC tests), then no doubt you regard this as a
lucky mistake :-)

Re: An interesting quote on Java and C++

[Robert I. Eachus]

In article <dewar.874759066@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > Of course if you find the non-binary modular stuff useful (I wonder how
 > much it is used outside ACVC tests), then no doubt you regard this as a
 > lucky mistake :-)

   One of the few places where it is useful is in random number
generation, so I was one of the few who felt a need for it.  However,
there is a related "trick" that occaisionally is useful.  Most
hardware architectures support a word * word --> doubleword multiply,
and a corresponding doubleword / word --> word instruction.  Of
course, these are not normally accesable from high-level languages
without implementation dependent techniques. To pick a specific
example, on the SPARC architecture, these instructions can follow one
after the other, but accessing the register holding the high order
bits is otherwise relatively slow.  So,

   type Modular is mod M; --for some non-static binary M.
   X, Y, Z: Modular;
   ...
   X := Y * Z;
   -- can be done in very few clock cycles.

   This is of course most interesting in any application where you are
interested in doing an integer FFT.  Comes up a lot in signal processing.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: An interesting quote on Java and C++

[Jon S Anthony]

Robert sez,

> be careful not to compare the reality of Ada with the Sun (and
> other) hype on Java. In the current state of things, Java is nowhere
> NEAR as portable as Ada, it is almost the normal case that an applet
> of any complexity written on one platform is likely not to work on
> another platform.

In our experience, this is putting the situation quite generously.
The stuff doesn't even work across releases or other JVMs on the
_same_ platform.


> Of course you can say, well that's because the implementations are
> decrepit, just wait and see, but then we are back to talking about
> implementatins and not languages.

Right (or at least I'm still willing to give them the benefit of the
doubt on this one for a while longer...)

> As for security, this is a matter of implementation, not the language.
> Indeed, there are all kinds of Java restrictions that must be adhered
> to for secure applet delivery that are not enforced by Java itself.
> And of coruse if you use an Ada->JVM system, then by definition this
> has the same level of security, since the security is implemented at
> the JVM level, not at the Java level.

Agreed.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: An interesting quote on Java and C++

[Stephen Leake]

Robert A Duff wrote:
>  <snip>
>   Consider also that
> Ada allows range constraints, which can help catch bugs, but provide no
> particular security benefit -- so Java takes the C attitude there
> (although more portable than C); Java can't say "type T is range
> 1..10;".

Range constraints provide significant security benefits, at least in
systems without separate address spaces. If you can write "past" the end
of an array, you can write to arbitrary memory, including system memory.
I believe there are several Windows/DOS viruses that use this trick, but
I'm not really sure.

> - Bob

-- 
- Stephe

Re: An interesting quote on Java and C++

[Roy Grimm]

Stephen Leake wrote:
> 
> Range constraints provide significant security benefits, at least in
> systems without separate address spaces. If you can write "past" the
> end of an array, you can write to arbitrary memory, including system
> memory.  I believe there are several Windows/DOS viruses that use this
> trick, but I'm not really sure.

A particularly famous example of missing range checking causing a major
security hole was that virus that took down hundreds of computers on the
internet several years ago.

The guy who built the virus used three known security holes to get his
virus around.  The one I can remember the best had to do with sending
specially formatted "finger" request packets.  The finger daemon on Unix
systems has a buffer to hold the incoming finger request data.  On some
particular flavor of Unix, if one decided to send a specially formatted
finger request packet (around 530 bytes if memory serves), they would
overrun the end of the buffer.

Now, overrunning the end of a buffer in many programs is not too
critical, if you consider a crash not too critical.  However, on
particular versions of unix, the finger daemon put executable code right
after that buffer.  When you overrun the end of that buffer, you
overwrite its code.  When the program gets to that code that you have
overwritten, it will do whatever you put there.  Since the finger daemon
runs with the system administrator's user ID on those systems, the code
you put in has global access to everything.  That's a major security
hole in anyone's book.

I believe the person who wrote the virus put in code which transferred
the main virus program from another site and then ran it, respawning the
finger daemon in the process so people wouldn't notice as easily.

Had there been range checking of the incoming request data along the
line, the hole would not be there.  

> - Stephe

-- 
Roy A. Grimm
Rockwell Collins Avionics, Cedar Rapids, Iowa
Voicing my own opinion, not speaking as a company representative.
All unsolicited email is quietly forwarded to /dev/null.

Re: An interesting quote on Java and C++

[Robert A Duff]

In article <3417ECEF.41C6@collins.rockwell.com>,
Roy Grimm  <ragrimm@collins.rockwell.com> wrote:
>Stephen Leake wrote:
>> 
>> Range constraints provide significant security benefits, at least in
>> systems without separate address spaces. If you can write "past" the
>> end of an array, you can write to arbitrary memory, including system
>> memory.  I believe there are several Windows/DOS viruses that use this
>> trick, but I'm not really sure.
>
>A particularly famous example of missing range checking causing a major
>security hole was that virus that took down hundreds of computers on the
>internet several years ago.

This is completely wrong.  You're talking about array-index checks, not
range checking (e.g. on integer values).  I was talking about the
latter, and I claim that range-checking is purely for catching bugs, and
has nothing to do with security (except in the sense that security
software without bugs is better than security software with bugs).

Java *does* do array-bounds checking, and that's for security reasons.
It does *not* do range checking on integers, and that does no damage to
security, but *does* cause bugs.  Ada has range checking, will helps get
rid of bugs, but it allows things like Unchecked_Conversion and pragma
Suppress, which totally destroy security.

Furthermore, the only way an array-index out of bounds can cause a
security flaw is when the program in question has a bug, and has some
privelege that most programs don't have.  E.g. setuid programs running
under unix.  (Or any program running under Windows 95!)

Yes, if a setuid program has a bug, it can cause a security flaw.  So
yes, bug-prevention in such programs can enhance security, indirectly.

>The guy who built the virus used three known security holes to get his
>virus around.  The one I can remember the best had to do with sending
>specially formatted "finger" request packets.  The finger daemon on Unix
>systems has a buffer to hold the incoming finger request data.  On some
>particular flavor of Unix, if one decided to send a specially formatted
>finger request packet (around 530 bytes if memory serves), they would
>overrun the end of the buffer.

Right, we're talking about array bounds checking, which Java and Ada
both have.  And we're talking about setuid programs, which can do real
damage when buggy.

>Now, overrunning the end of a buffer in many programs is not too
>critical, if you consider a crash not too critical.  However, on
>particular versions of unix, the finger daemon put executable code right
>after that buffer.  When you overrun the end of that buffer, you
>overwrite its code.  When the program gets to that code that you have
>overwritten, it will do whatever you put there.  Since the finger daemon
>runs with the system administrator's user ID on those systems, the code
>you put in has global access to everything.  That's a major security
>hole in anyone's book.

Yes, if you can overwrite arbitrary addresses in a priveleged program,
then you've got a security hole.  But that's got nothing to do with
bounds-checking on integers.

>I believe the person who wrote the virus put in code which transferred
>the main virus program from another site and then ran it, respawning the
>finger daemon in the process so people wouldn't notice as easily.
>
>Had there been range checking of the incoming request data along the
>line, the hole would not be there.  

No, array-bounds checking is what was missing.

- Bob

Re: An interesting quote on Java and C++

[Jon S Anthony]

In article <EG9rCz.5pH@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> Beats me.  But it's clear from the Java language documents that two
> goals of Java are (1) avoid security flaws, and (2) portability at the
> cost of efficiency.
> 
> Ada meets neither of those goals.  (1) Ada allows dangling pointers and
> so forth, and (2) Ada's arithmetic model favors efficiency over
> portability.

However, the real odd thing is that Java doesn't meet these goals
either.  At least not at last count...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: An interesting quote on Java and C++

[Robert Dewar]

iRobert Duff said

<<>Surely you're not saying that Ada (as is) meets the goals of Java>>

Certainly not, the goal of Java is to make money for Sun (it's not really
meeting its goal very well yet :-)

Re: An interesting quote on Java and C++

[Jon S Anthony]

In article <dewar.873953246@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> iRobert Duff said
> 
> <<>Surely you're not saying that Ada (as is) meets the goals of Java>>
> 
> Certainly not, the goal of Java is to make money for Sun (it's not really
> meeting its goal very well yet :-)

ROTFLOL!!

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: An interesting quote on Java and C++

[Robert A Duff]

>In article <dewar.873953246@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>> iRobert Duff said
>> 
>> <<>Surely you're not saying that Ada (as is) meets the goals of Java>>
>> 
>> Certainly not, the goal of Java is to make money for Sun

Granted.

I must say, though, that any damage to the theoretical portability of
the Java standard, caused by implementations of Java disobeying that
standard (by accident or on purpose), seems to damage Sun's ultimate
goal, here.  Sun's competitor(s) of course have every incentive to
produce so-called Java implementations that have nice little extensions
and other "minor" differences.

>>... (it's not really
>> meeting its goal very well yet :-)

- Bob

Re: An interesting quote on Java and C++

[Marin David Condic, 561.796.8997, M/S 731-96]

Robert A Duff <bobduff@WORLD.STD.COM> writes:
>Note that modular types are not just about modular arithmetic -- they
>also support bit-wise logical operations.  On a one's complement
>machine, you still want to be able to have all-ones as a bit pattern, if
>you're using these things as bit patterns, even though it's
>arithmetically equal to zero.
>
    This gets me curious about the possibility that we may be spending
    lots of time in the Ada standard dealing with things that are
    non-issues. I ask out of ignorance: Are there any reasonably
    popular microprocessors that are *not* twos-compliment machines? I
    don't think I've ever had occasion to work with a ones-compliment
    microprocessor. If there are some ones-compliment machines out
    there in large numbers, has anyone ever built an Ada compiler for
    them? Would there be any real interest in doing so or are they too
    specialized to expect Ada to suddenly become popular on them?

    It's a little like agonizing over making it convenient to port Ada
    to a DEC-10 processor with a 36bit word. That architecture has
    long since been relegated to history (and I occasionaly miss it!)
    and just about everything in significant use today uses a 16bit,
    32bit or maybe 64bit word. So we can write an Ada standard that
    conveniently maps the standard Integer types to these limits and
    not worry if there's some obscure machine that won't find this
    handy.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "Cross country skiing is great if you live in a small country."

        --  Steven Wright
===============================================================================

Re: An interesting quote on Java and C++

[Shmuel (Seymour J.) Metz]

Marin David Condic, 561.796.8997, M/S 731-96 wrote:
> 
>     This gets me curious about the possibility that we may be spending
>     lots of time in the Ada standard dealing with things that are
>     non-issues. I ask out of ignorance: Are there any reasonably
>     popular microprocessors that are *not* twos-compliment machines? 

AFAIK the only processors around that are not two's complement are:

	Burroughs processors that have been upgraded by Unisys

	CDC 6x00 and Cyber line; no longer in production

	DEC System-20 (still used by CompuServe)

	GE 600/6000 line, now BULL DPS 8 or some such

	Univac 1100 line, now Unisys 2200

All of these have small and declining market shares. I don't know 
whether there is an Ada compiler for any of these, but I suspect that
Mr.
Dewar would know. I doubt that there would be an economic incentive to
do
a new compiler for any of them.
 
>     It's a little like agonizing over making it convenient to port Ada
>     to a DEC-10 processor with a 36bit word. That architecture has
>     long since been relegated to history (and I occasionaly miss it!)

As I noted above, the DEC PDP-6/PDP-10 line is not quite dead;
CompuServe 
is still using it, although the hardware comes from a third party
vendor.
 
>     MDC
> 
> Marin David Condic, Senior Computer Engineer   

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: An interesting quote on Java and C++

[Tucker Taft]

Shmuel (Seymour J.) Metz (nospam@gsg.eds.com) wrote:

: AFAIK the only processors around that are not two's complement are:

: ...
: 	DEC System-20 (still used by CompuServe)

This has a 36 bit word, but it is a 2's complement machine.

: ...
: 	Univac 1100 line, now Unisys 2200

: All of these have small and declining market shares. I don't know 
: whether there is an Ada compiler for any of these, but I suspect that
: Mr.
: Dewar would know. I doubt that there would be an economic incentive to
: do
: a new compiler for any of them....

There is an Ada 95 compiler for the Unisys 2200, built by RR Software.

: ...
:                         Shmuel (Seymour J.) Metz
:                         Senior Software SE

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: An interesting quote on Java and C++

[Robert I. Eachus]

In article <342AD83E.2C92@gsg.eds.com> "Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> writes:

   AFAIK the only processors around that are not two's complement are...

   Ever use floating point?  On most hardware today, floating point
uses a (biased)two's-complement exponent and a sign and magnitude
mantissa.  So if you use the floating point engine to do integer
arithmetic you get similar semantics to one's complement.  (Signed
zeros and range symmetric around zero.)

   Incidently Ada 95 makes it much easier to write code that does
exact integer arithmetic using floating point types.  This is
important on many processors as the floating-point multiplication unit
is faster than the integer multiply, and can be done in parallel with
other operations.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: An interesting quote on Java and C++

[Shmuel (Seymour J.) Metz]

Robert I. Eachus wrote:

>    Ever use floating point?  On most hardware today, floating point
> uses a (biased)two's-complement exponent and a sign and magnitude
> mantissa.  So if you use the floating point engine to do integer
> arithmetic you get similar semantics to one's complement. 

Not even close; no end around carry, and the arithmetic complement is
not the bitwise complement. One's complement, for better or for worse,
is not like anything you're used to except for one obscure thing that
I'll leave as an exercise for the reader.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: An interesting quote on Java and C++

[Marin David Condic, 561.796.8997, M/S 731-96]

"Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG> writes:
>In article <342AD83E.2C92@gsg.eds.com> "Shmuel (Seymour J.) Metz"
><nospam@gsg.eds.com> writes:
>
>   AFAIK the only processors around that are not two's complement are...
>
>   Ever use floating point?  On most hardware today, floating point
>uses a (biased)two's-complement exponent and a sign and magnitude
>mantissa.  So if you use the floating point engine to do integer
>arithmetic you get similar semantics to one's complement.  (Signed
>zeros and range symmetric around zero.)
>
    That's a good point. One of those things you're maybe aware of,
    but never made the connection...

    I had originally posted a question on the subject of one's
    compliment (rather as an aside) because I was wondering why Ada
    would feel the need to support potentially obscure hardware at the
    possible expense of implementation complexity. One of the examples
    was defining standard integers such that they could be supported
    on a one's compliment machine.

    Granted, this isn't a big deal in terms of implementation
    complexity. There may be better examples. But it seems there's a
    real dearth of one's compliment architectures out there for which
    anyone has a serious interest in porting Ada. Is there any
    technical advantage to one's compliment? AFAIK, there's no
    significant math advantage and possibly only some small hardware
    advantage. Apparently nothing big enough to warrant that becoming
    the dominant technology.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
===============================================================================
    "Eagles may soar, but a weasle never gets sucked up into a jet engine."
===============================================================================

Re: An interesting quote on Java and C++

[Shmuel (Seymour J.) Metz]

Marin David Condic, 561.796.8997, M/S 731-96 wrote:
> 
>     Granted, this isn't a big deal in terms of implementation
>     complexity. There may be better examples. But it seems there's a
>     real dearth of one's compliment architectures out there for which
>     anyone has a serious interest in porting Ada. Is there any
>     technical advantage to one's compliment? 

One's complement has the advantage that the arithmetic and logical not 
operations are the same. Also, I understand that you can save a few
gates
in the adder by using one's complement. But I would be astounded if
anyone designed a new architecure using one's complement. As a practical
matter, one's complement will only exist in legacy Univac equipment and
the Unisys replacements. 

>     MDC

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org