Re: Ada and Java. different behaviour. casting long to int problem.

Re: Ada and Java. different behaviour. casting long to int problem.

[kirck]

In article <yecbtel9f95.fsf@king.cts.com>, Keith says...

>
>stt@houdini.camb.inmet.com (Tucker Taft) writes:
>> Integer conversion (casting) in Java is truncating.
 
>
>Actually, Java follows *de facto* C/C++ semantics.  In C and C++,
>unsigned integer arithmetic is defined to wrap around, but overflow on
>signed integer arithmetic produces undefined behavior.  

Ok, so the bottom line of all this, is that Java (and C and C++) all
blew it, and Ada did not.

I hope I do not see Java used to implement the software that will
launch the next rocket to space, or process my bank financial statment.
 
I'd rather see a language that catches such basic errors on the spot
like Ada did in the example, not hide them under the cover.

Kirck.

Re: Ada and Java. different behaviour. casting long to int problem.

[Fred]

In article <7jvcqv$od9$1@nnrp1.deja.com>, Robert says...
>
 
>> Ok, so the bottom line of all this, is that Java (and C and
>> C++) all blew it, and Ada did not.

>
>I disagree strongly with this statement. Java has well defined
>portable semantics for its arithmetic operations. It is the
>programmers responsibility to know these semantics and use them
>in an appropriate manner.
>

OK, so you are in the middle of lengthy calculation, with some
intermediate results being generated on the fly, and an
overflow occurs.

In Java, nothing happens, and life goes on and the final number is wrong,
but no one really knows it is wrong, or may be someone will notice it is
wrong.

In Ada, the overflow is detected the second it occurs, and the programmer
can go and fix the calculation, or the data types for some of the variables
involved. 

Your answer to all this, is that with Java, even if the final answer is wrong,
it is OK, since that is how Java is defined to work, and the programmer,
somehow must have anticipated every possible value that can occur, even
in intermediate transit calculations to make sure no overflow will occur, and
it is the fault of the programmer.

You might be right actually. may be the programmer should have. but if 
you want to put your life on-line dependent on some program, which one 
of the above two language would you choose to write the software with? 
I know which one I'll choose. 

>A programmer who casually expects Java to check for overflow
>in a situation where it is well defined that it does not is
>incompetent, and it is unreasonable to blame Java for such
>incompetence.
...
>There is no basic error here in the Java case, just a
>misunderstanding by the programmer. If you don't know the
>rules of your language, you may well make a mess of things!

Following your logic, no one in the Ada groups should ever criticize C++ or C 
any more, since C/C++ is well defined as well, even though the way it is 
defined can lead to problems, it is the responsibility of the programmer 
not to fall into these problems and it is not reasonable to blame C or C++
for such problems.  When someone moves a long into a char in C, with loss
of data, and the compiler and the run-time not detecting this, do not blame C
then when that train crashes killing 50 people, Blame the programmer, becuase
it is well defined in C that it is allowed to move long into a char.

No thank you, I'd rather depend on a language defined to catch such errors, 
rather than depending on each programmer manually detecting such problems
for each step of the program. humans do make mistakes, that is why we invent
languages that are strongly typed to help programmers find such mistakes. 

Fred

 
 

Ada and Java. different behaviour. casting long to int problem.

[nabbasi]

This below shows that Ada detected at compile time a basic problem
that the Java compiler missed. (this might be specific problem
with the Java compiler I am using), it also could be a 
mis-understanding on my part of the Java semantics when it 
comes to this, but the bottom line is that Java produced, 
what for me, can only be a wrong result.

Please do not make this thread a language-war, (I happen to
like both Java and Ada), but I am really only interested in 
someone explaining the justification behind this Java behavior.

In the example, I cast a long integer literal, outside the range
of an integer, into an integer variable.  Java allows this,
and produces the wrong result. Ada compiler detect this as an error
at compile time, and it also detects the same thing at run-time.

fyi: a 64 bit signed long range is -9223372036854775808 .. 9223372036854775807 
and an 32 bit signed integer range is  -2147483648 .. 2147483647

In the example, I cast the literal 3200000000, which is clearly outside
the range of an integer, into an integer. I expect the compiler or
the run-time, to detect this. Ada does, Java did not. Is this by 'design'
on the part of Java? i.e. is this how Java supposed to behave? becuase
this can result in very wrong calculations if not detected.

env:
----
OS: linux 2.0.36
Java compiler: free JDK from http://www.blackdown.org 1.2, also 1.1.7B
Ada compiler : free ada95 GNAT compiler from http://www.gnat.com, version 3.11p

---------------- java example 1-----------------------------
class test_cast
{
   public static void main(String args[])
   {
      long n= 3200000000L;
      int  m= (int) n;
      System.err.println("long n =" + n + " int m=" + m);
   }
}

$javac  ./test_cast.java      <-- compile OK

$java test_cast               <--- runs OK and produces 'wrong' result.
long n =3200000000 int m=-1094967296
$
----------------------------- Ada example 2 -----------------
with Ada.Text_Io;         USE Ada.Text_Io;

procedure Test_Cast is
   n : Long_Integer := 3200000000;
   m : Integer      := Integer (N);
begin
      Put_Line (   "long n ="  &  Long_integer'Image(N)
                 & "int  m ="  &  Integer'Image(M) );
end Test_Cast;

$gnatmake test_cast.adb
gnatgcc -c test_cast.adb
test_cast.adb:5:24: value not in range of type "Standard.Long_Integer"
test_cast.adb:5:24: static expression raises "Constraint_Error"
gnatmake: "test_cast.adb" compilation error
$

--------------------------------------------------------------------

Now, lets try the same idea as above, but do not use a literal
number (so to not allow the ada compiler the chance to detect this
at compile time) and try to do the same at run-time.


------------------- ada example 2 -----------------------------

with Ada.Text_Io;         USE Ada.Text_Io;

procedure Test_Cast is
   N  : Long_Integer;
   M  : Integer;
   package Long_Int_Io  is new Ada.Text_Io.Integer_Io(Long_Integer);
begin
   Long_Int_Io.Get(N);
   M := Integer (N);

   Put_Line (   "long n ="  &  Long_integer'Image(N)
              & "int  m ="  &  Integer'Image(M) );
end Test_Cast;

$gnatmake -gnatf test_cast.adb    <-- compile OK
gnatgcc -c -gnatf test_cast.adb
gnatbind -x test_cast.ali
gnatlink test_cast.ali

$./test_cast                  <--- run
3200000000

raised ADA.IO_EXCEPTIONS.DATA_ERROR   <-- exception raised
-------------------------------------------------------------


comments?

Nasser

Re: Ada and Java. different behaviour. casting long to int problem.

[nabbasi]

In article <7jt2c0$vrb@drn.newsguy.com>, nabbasi@pacbell.net says...
 
>In the example, I cast a long integer literal, outside the range
>of an integer, into an integer variable.  Java allows this,
>and produces the wrong result. Ada compiler detect this as an error
>at compile time, and it also detects the same thing at run-time.
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

actually that was an error of mine, it did not detect it at run-time,
only at compile time. see below
 
>------------------- ada example 2 -----------------------------
>
>with Ada.Text_Io;         USE Ada.Text_Io;
>
>procedure Test_Cast is
>   N  : Long_Integer;
>   M  : Integer;
>   package Long_Int_Io  is new Ada.Text_Io.Integer_Io(Long_Integer);
>begin
>   Long_Int_Io.Get(N);
>   M := Integer (N);
>
>   Put_Line (   "long n ="  &  Long_integer'Image(N)
>              & "int  m ="  &  Integer'Image(M) );
>end Test_Cast;
>

>$./test_cast                  <--- run
>3200000000
>
>raised ADA.IO_EXCEPTIONS.DATA_ERROR   <-- exception raised
>-------------------------------------------------------------
 
This was an input error which I do not understand now why.

This is a modified Ada program, that shows Ada did not detect at
run-time the overflow (I think may be I am not using the correct 
GNAT flag to enable run-time chekcing? I need to check more on this)

-------------------------------------
with Ada.Text_Io;         USE Ada.Text_Io;

procedure Test_Cast is
   N  : Long_Integer;
   M  : Integer;
   package Long_Int_Io  is new Ada.Text_Io.Integer_Io(Long_Integer);
begin
   N := 2000000000;
   M := Integer (N);
   M := M*2;

   Put_Line (   "long n ="  &  Long_integer'Image(N)
              & "int  m ="  &  Integer'Image(M) );
end Test_Cast;
------------------------------------------
 
$./test_cast
long n = 2000000000int  m =-294967296
                        ^^^^^^^^^^^^^^ 
                            ???
Nasser
    

Re: Ada and Java. different behaviour. casting long to int problem.

[jerry]

nabbasi@pacbell.net.NOSPAM wrote:

: This is a modified Ada program, that shows Ada did not detect at
: run-time the overflow (I think may be I am not using the correct 
: GNAT flag to enable run-time chekcing? I need to check more on this)

The super-secret GNAT documentation will tell you that this is a very
expensive check to perform, so it is by default disabled. Use the
-gnato flag to enable it.

Personally I always compile with '-g -gnato' unless there is a good
reason not to.

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert Dewar]

In article <FD7nFF.6D@stuyts.nl>,
  jerry@jvdsys.stuyts.nl wrote:
> nabbasi@pacbell.net.NOSPAM wrote:
>
> The super-secret GNAT documentation will tell you that this is
> a very
> expensive check to perform, so it is by default disabled.

The very here is Jerry's invention :-)

The actual quote from the documentation is:

  We treat integer overflow specially
  because these are quite expensive and in our experience are
  not as important as other run-time checks in the development
  process.

and the "quite" here is probably right. We have in fact steadily
improved the quality of code for -gnato, so the penalty has been
reduced. It would be interesting to know what actual programs
see as a result of -gnato being off or on.

Note that the reason that overflow checking is rather different
from other checks is that it does not introduce safety issues.
You may get unexpected (e.g. modular wrapped) values, but you
don't get wild jumps, loads or stores as a result of overflow
checking being off.








> -- Jerry van Dijk | Leiden, Holland
> -- Team Ada       | jdijk@acm.org
> -- see http://stad.dsl.nl/~jvandyk
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada and Java. different behaviour. casting long to int problem.

[Tucker Taft]

nabbasi@pacbell.net wrote:

: This below shows that Ada detected at compile time a basic problem
: that the Java compiler missed. (this might be specific problem
: with the Java compiler I am using), it also could be a 
: mis-understanding on my part of the Java semantics when it 
: comes to this, but the bottom line is that Java produced, 
: what for me, can only be a wrong result.

Integer conversion (casting) in Java is truncating.  Integer conversion in 
Ada is value-preserving, with a run-time check on overflow (note that
GNAT in some configurations suppresses overflow checks by default,
which is naughty in some people's view ;-).  To get truncation in Ada,
you need to use an explicit "mod"/"rem" or Unchecked_Conversion.

Java is largely following C/C++ semantics in this area, FWIW,
though C/C++ provide *implicit* truncating conversions, whereas
truncating conversions in Java must be explicit casts.

: ...
: Nasser

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada and Java. different behaviour. casting long to int problem.

[PPAATT]

> truncating conversions in Java must be
> explicit casts.

Java casts need be explicit only if they convert a one to a sign bit or if they
truncate one's.  Truncating zeroes remains (yeeuck) implicit e.g.

        final int i = 0x7F;
        byte b = i;

And the rules on how many sign-extension bits to add implicitly have changed
for the shift operators and for the ?: if-then-else operator.


Pat LaVarre   p.lavarre@ieee.org   http://members.aol.com/ppaatt/nqjava/

Re: Ada and Java. different behaviour. casting long to int problem.

[Keith Thompson]

stt@houdini.camb.inmet.com (Tucker Taft) writes:
[...]
> Integer conversion (casting) in Java is truncating.
[...]
> Java is largely following C/C++ semantics in this area, FWIW,
> though C/C++ provide *implicit* truncating conversions, whereas
> truncating conversions in Java must be explicit casts.

Actually, Java follows *de facto* C/C++ semantics.  In C and C++,
unsigned integer arithmetic is defined to wrap around, but overflow on
signed integer arithmetic produces undefined behavior.  Almost all
existing implementations provide wraparound on signed overflow, but
it's not required by the language definitions.

All this is from memory; please correct me (gently) if I'm mistaken.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert Dewar]

In article <FD85Lq.Hyp.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> Ada is value-preserving, with a run-time check on overflow
> (note that GNAT in some configurations suppresses overflow
> checks by default,
> which is naughty in some people's view ;-).

There is no requirement that the "default" (whatever that
may mean) mode of an Ada compiler be the mode in which it
is standard compliant. The only requirement is that there
is a way of running the compiler that is standard compliant
(and of course the VSR for the validation says exactly which
set of switches were used for validation).

While one can argue about the choice of overflow checks off,
constraint checks on being the default, we strongly feel that
being standard compliant in other respects is quite the wrong
default. In particular, the rather dangerous dynamic approach
to elaboration checking that is mandated by the standard is
of course available in GNAT (using the -gnatE switch), but we
consider it considerably inferior to the default static
elaboration analysis which is the default mode. In this default
mode, the compiler can determine a guaranteed safe order of
elaboration for almost all cases, which is much better than
having to delay the checks till run time.

But in any case, an important rule is *read the documentation*
of whatever compiler you are using, and in particular be careful
to know what all the options available for compilation are.
GNAT has quite a long list of compilation switches, and many
of them are quite useful (for example, it is a very good idea
to use -gnatwu for nearly all compilations -- and if you don't
know what -gnatwu does, go look it up :-)

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert Dewar]

In article <7jv4bh$11rg@drn.newsguy.com>,
  kirck@nospam.com wrote:

> Ok, so the bottom line of all this, is that Java (and C and
> C++) all blew it, and Ada did not.

I disagree strongly with this statement. Java has well defined
portable semantics for its arithmetic operations. It is the
programmers responsibility to know these semantics and use them
in an appropriate manner.

A programmer who casually expects Java to check for overflow
in a situation where it is well defined that it does not is
incompetent, and it is unreasonable to blame Java for such
incompetence.

Now one may argue about whether Java's semantic choice is the
right one, and I certainly prefer the Ada choice, but I think
it is too harsh to say that "Java blew it", there is nothing
fundamentally more moral or correct about Ada's semantics here.
We are simply talking about the pragmatic issue of which
semantic model makes it easier to write reliable programs.

> I hope I do not see Java used to implement the software that
> will launch the next rocket to space, or process my bank
> financial statement.

Competent programmers can certainly write realiable software
in Java for these functions. I agree it is *easier* to write
the same reliable software in Ada, but trying to imply that
Java is somehow fundamentally unsafe is another case of
excessive negative comment on non-Ada languages by Ada advocates
and that is not helpful!

> I'd rather see a language that catches such basic errors on
> the spot like Ada did in the example, not hide them under the
> cover.

There is no basic error here in the Java case, just a
misunderstanding by the programmer. If you don't know the
rules of your language, you may well make a mess of things!
In Java if you add 1 to the largest positive number, you get
the most negative number. This is not an error, let alone a
basic error, it is simply what adding 1 is defined to do!

Now if this is NOT the function you need, and instead you need
to check that the result does not exceed the largest positive
number, you need to program the check that you need. Yes, it is
easier in Ada to do this check, but that does not mean that
there is something fundamentally unsafe about Java here.



Robert


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada and Java. different behaviour. casting long to int problem.

[tmoran]

>to use -gnatwu for nearly all compilations -- and if you don't
>know what -gnatwu does, go look it up :-)
Where?
It's in neither gnat_ug.txt nor gnat_rm.txt, dated 1/7/99.

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Robert Dewar wrote:
> 
> and the "quite" here is probably right. We have in fact steadily
> improved the quality of code for -gnato, so the penalty has been
> reduced. It would be interesting to know what actual programs
> see as a result of -gnato being off or on.
> 
Out of curiosity, I'm wondering what makes trapping an integer overflow
& raising an exception expensive. I know that lots of processors provide
some form of interrupt in the event of an operation resulting in an
integer overflow. That usually means that detection is not intrusive. Or
is it a problem of efficiency only when riding on top of an OS like Unix
where you may not easily be able to specify behavior for a hardware
interrupt?

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Mark Hood]

Fred@moon.com.spam_free writes:
> OK, so you are in the middle of lengthy calculation, with some
> intermediate results being generated on the fly, and an
> overflow occurs.
> 
> In Java, nothing happens, and life goes on and the final number is wrong,
> but no one really knows it is wrong, or may be someone will notice it is
> wrong.

I think the point is that the result of an overflow isn't necessarily the
wrong number.  

For example, one could be working with data that needs to be expressed in
some signed 16-bit quantized space, and wish to encode consecutive elements
in that space as deltas from previous values in a streamed fashion.  In that
case the overflow semantics are essential, since otherwise it wouldn't be
possible to express the delta between -30000 and +30000 in 16 bits.

The example isn't contrived; it's common in compression algorithms.  My
impression is that Ada is oriented toward numerical applications, and so the
overflow checks are probably appropriate.  It would certainly be
inconvenient for many Java applications if the defined behavior of signed
2's complement integers were thwarted.

-- Mark Hood

Re: Ada and Java. different behaviour. casting long to int problem.

[Samuel Mize]

In comp.lang.ada mike@world.nospam.com wrote:
> In article <f92d7yyweva.fsf@eng.sun.com>, Mark says...
>>
>>I think the point is that the result of an overflow isn't necessarily the
>>wrong number.  
>>
>  
> I wonder if the above will be stand in court when a bank customer complains
> to the judge that they deposited $5,000 into their saving account
> in top of what allready they had in there, only to be told by the bank
> that now they have a negative balance.

No, it won't, because anyone who can overflow a bank's accounting
software can buy whatever verdict he wants.  :-)

More seriously, saying it "isn't necessarily" wrong doesn't mean that
it's always right.  It means you have to know what the numerical
model does, and handle that behavior appropriately.

The programmer is at fault, because he didn't know (or properly use)
the Java numerical model.

The bank is liable since he's their programmer.

The compiler vendor is not at fault -- the object code exactly matched
the program, since it's using the Java numerical model.

Nor is the Java model "wrong" -- it just doesn't match the mathematical
abstraction of "integer."  In fact, Ada doesn't either (I don't recall
"constraint error" from ANY math classes).

The two models map the mathematical abstraction to the real-world
limited representation in different ways.  For numerical computation
the Ada version is more useful.  For traditional, C-oriented system
programming, and for some other kinds of algorithms, the Java model
is more useful.

Models of anything are never true or false, only more or less useful.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

mike@world.nospam.com wrote:
> 
> 'The result of an overflow isn't necessarily the wrong number' the bank
> attorney replies. (flaged on the side by the bank top Java consultant ready
> to supply more therotical evidence that supports such a statment).
> 
I'm of the opinion that if one wishes behavior different from that of
"normal" arithmetic, then this should be specified by a type with
special properties. One acustomed to normal arithmetic is going to
believe that X := X + 1 will yield the successor of X in the set of all
integer numbers. If that isn't possible because of real world
limitations, then we have encountered an exceptional condition which
ought to raise some sort of flag and warn the world that the anticipated
behavior was not achieved. If one wants wraparound semantics, then
perhaps there should be a special type to support that behavior - a la
modular types in Ada. (Although these don't contain negative numbers and
that may be a requirement.) In some cases, saturation semantics are a
good thing, but again, this is not the "normal" understanding of
arithmetic and therefore should be supported by a special type.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Mike Silva]

I agree completely.  To my mind, quietly producing a non-intuitive result
(via truncation or wraparound) is in the same league as being able to
quietly step off the end of an array (something the Java folks beat up on
the C/C++ folks about constantly).

Mike

Marin David Condic wrote in message <3766650F.705125B7@pwfl.com>...

>I'm of the opinion that if one wishes behavior different from that of
>"normal" arithmetic, then this should be specified by a type with
>special properties. One acustomed to normal arithmetic is going to
>believe that X := X + 1 will yield the successor of X in the set of all
>integer numbers. If that isn't possible because of real world
>limitations, then we have encountered an exceptional condition which
>ought to raise some sort of flag and warn the world that the anticipated
>behavior was not achieved.

Re: Ada and Java. different behaviour. casting long to int problem.

[rich]

In article <7k64t7$igo$1@its.hooked.net>, "Mike says...
>
>I agree completely.  To my mind, quietly producing a non-intuitive result
>(via truncation or wraparound) is in the same league as being able to
>quietly step off the end of an array (something the Java folks beat up on
>the C/C++ folks about constantly).
>
 
I agree also.

But to play devil advocate, and using similar argument allready given to us
in this thread, one can reply: as long as the language is defined to behave 
this way, it becomes the programmer resposibility, and any unexpected
behaviour resulting from using such language means the programmer is
incompetent.
 

So, as long as C/C++ is defined not to do array boundary checking (which it is),
then no one has the right to critisize such languages, and incompetent 
programmers need to understand this.

And as long as java is defined that it can produce a negative value when
adding 2 positive values, and without *any kind of warning* to the programmer,
then it becomes the resposibility of the programmer to understand this,
and a programmer that produces a program that fails to check everywhere
for this, is an incompetent programmer.

Of course the above argument is all a big ballony, but this is the defense
people are comming up with to justify this. It looks like when a language
is popular, it can do any strange things, and people will still defend it.

Rich

Re: Ada and Java. different behaviour. casting long to int problem.

[Samuel Mize]

In comp.lang.ada rich@nowhere.com wrote:
> In article <7k64t7$igo$1@its.hooked.net>, "Mike says...
>>
>>I agree completely.  To my mind, quietly producing a non-intuitive result
>>(via truncation or wraparound) is in the same league as being able to
>>quietly step off the end of an array (something the Java folks beat up on
>>the C/C++ folks about constantly).
...
>one can reply: as long as the language is defined to behave 
> this way, it becomes the programmer resposibility, and any unexpected
> behaviour resulting from using such language means the programmer is
> incompetent.

I'd like to make my opinion a little clearer than that!

Getting an exception is usually BETTER.  But it's no more abstractly
correct than wrapping around or truncating.

ANY efficient representation is going to compromise the abstraction
"integer."  When you add two abstract integers, wrapping around is
wrong; truncating is wrong; raising an exception is wrong.  I have
yet to see a math book that discussed exceptions!

There are times where each of these is right, or at least useful.
And, there are times when each of them can cause problems.

The ideal language would make all three options available, at the
programmer's discretion.  Say -- Ada does that!  If you overload
the functions yourself, so does Java.

So I'd agree that Ada is more convenient, and that its default
behavior is more likely to be what a math-trained user would expect.

That doesn't make Java and C "wrong," just harder to use well.


> So, as long as C/C++ is defined not to do array boundary checking (which
> it is), then no one has the right to critisize such languages,

No, I'd say you have every right to criticize the language.  I just
wouldn't say the language is WRONG.  I'd say it's weaker, that it
helps you less, and that it has a more primitive model of arrays.


> then it becomes the resposibility of the programmer to understand this,
> and a programmer that produces a program that fails to check everywhere
> for this, is an incompetent programmer.

If we're talking about someone who writes software assuming that no
computation will exceed the bounds of the representation, without any
analysis, then "incompetent" is probably fair.

Whether it produces a wrong number or just crashes, it will fail
in a spectacular way after delivery.

But note that in the example of a bank account, a bad result will
require some kind of corrective transaction, while an unhandled
exception may cause a crash, leaving parts of the bank's system in
an undefined state.  Putting in exception handlers that would keep
the transaction correct will require as much analysis as if you
were using Java and had to avoid wrap-around.

In short, I think that calling Java/C "wrong" is unfair here, as
unfair as complaining that a harpoon makes a bad hammer.  But it's
certainly fair to say that more people need hammers than harpoons!

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

rich@nowhere.com wrote:
> 
> But to play devil advocate, and using similar argument allready given to us
> in this thread, one can reply: as long as the language is defined to behave
> this way, it becomes the programmer resposibility, and any unexpected
> behaviour resulting from using such language means the programmer is
> incompetent.
> 
Spending time transferring blame is one of the least productive
activities known to man. The people burnt to a crisp in the crash of an
airplane aren't going to care that "The Programmer Should Have Read The
Standard Better." Dead is just as dead if it was the compiler that was
at fault. What the programmer *should* do is mostly irrelevant. What the
programmer is *likely* to do is go with all of his years of grade school
arithmetic and casually believe that X := X + 1 will yield the expected
result.

> 
> So, as long as C/C++ is defined not to do array boundary checking (which it is),
> then no one has the right to critisize such languages, and incompetent
> programmers need to understand this.
> 
Blaming the programmer doesn't make the bugs not happen. Its like having
loose carpeting on the stairs and when someone trips and breaks their
neck, we stand around saying "He should have looked where he was going."
The poor dumb bastard is dead, dead, dead, and a couple of carpet tacks
would have prevented it.

> And as long as java is defined that it can produce a negative value when
> adding 2 positive values, and without *any kind of warning* to the programmer,
> then it becomes the resposibility of the programmer to understand this,
> and a programmer that produces a program that fails to check everywhere
> for this, is an incompetent programmer.
> 
And again, a *competent* assembly language programmer wouldn't make
mistakes in doing math in assembly language because the hardware
behavior is very thoroughly defined. Yet ever since Adam bit the apple,
we've all been plagued by bouts of stupidity and maliciousness. The
latter is something a language can do little about, but the former we
can take action against. Why do we build electrical connectors that can
only be put together one way? Because if there are *two* ways to do it
and one of them is wrong, sooner or later someone will plug them in
together the wrong way. Calling them incompetent doesn't unplug the
connectors and get them right, nor does it put back all of the smoke
that was let out of the electronic device.

> Of course the above argument is all a big ballony, but this is the defense
> people are comming up with to justify this. It looks like when a language
> is popular, it can do any strange things, and people will still defend it.
> 
Good argument. I hereby bestow upon you the rank of Devil's Advocate,
First Class, with Oak Leaf Clusters. :-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[jerry]

Samuel Mize <smize@imagin.net> wrote:

: No, it won't, because anyone who can overflow a bank's accounting
: software can buy whatever verdict he wants.  :-)

Perhaps, but I have seen it happening, though not on private accounts, but
in foreign currency transfers (think like : General Motors paying the bill in 
the yen...).

Of course, there was no overflow but an error. Banks use fixed point 
arithmatic. It is actually a reason why PL/I is still in use, Cobol,
like Ada, garantees 18 digits accuracy and that sometimes is not
enough. IBM's PL/I compiler offers 22 digit accuracy for it's fixed point
arithmatic.

Ahh, well, back to Ada...

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Ada and Java. different behaviour. casting long to int problem.

[tmoran]

>then it becomes the resposibility of the programmer to understand this,
>and a programmer that produces a program that fails to check everywhere
>for this, is an incompetent programmer.
  A language that needs perfect programmers will have few programmers.

Re: Ada and Java. different behaviour. casting long to int problem.

[mike]

In article <f92d7yyweva.fsf@eng.sun.com>, Mark says...
>
 
>
>I think the point is that the result of an overflow isn't necessarily the
>wrong number.  
>
 
I wonder if the above will be stand in court when a bank customer complains
to the judge that they deposited $5,000 into their saving account
in top of what allready they had in there, only to be told by the bank
that now they have a negative balance.

'The result of an overflow isn't necessarily the wrong number' the bank
attorney replies. (flaged on the side by the bank top Java consultant ready
to supply more therotical evidence that supports such a statment).


Mike.

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

mike@world.nospam.com wrote:

> In article <f92d7yyweva.fsf@eng.sun.com>, Mark says...

> >I think the point is that the result of an overflow isn't necessarily the
> >wrong number.

> I wonder if the above will be stand in court when a bank customer complains
> to the judge that they deposited $5,000 into their saving account
> in top of what allready they had in there, only to be told by the bank
> that now they have a negative balance.

> 'The result of an overflow isn't necessarily the wrong number' the bank
> attorney replies. (flaged on the side by the bank top Java consultant ready
> to supply more therotical evidence that supports such a statment).

I think you missed the implied - "depending on what the number
is being used for".

Reading this thread... it would be nice to have a Java compiler
that could generate checkes for overflows etc... perhaps a
new keyword like they did with 'strictfp'.

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

Marin David Condic wrote:

> What the
> programmer is *likely* to do is go with all of his years of grade school
> arithmetic and casually believe that X := X + 1 will yield the expected
> result.

I'd disagree that wrapping around is not intuitive... it can be a 
PITA... but it is intuitive.  Since the language defines the behavious
the programer _HAS_ to work withing the constraints set out in the
language spec.

Now should the language be defined differently... mabey.

If the programer doesn;t follow the langauge spec then the fault is
100% theirs.


> Blaming the programmer doesn't make the bugs not happen. Its like having
> loose carpeting on the stairs and when someone trips and breaks their
> neck, we stand around saying "He should have looked where he was going."
> The poor dumb bastard is dead, dead, dead, and a couple of carpet tacks
> would have prevented it.

If your sent into a room that is full of pins sticking up from the
floow - and you are tole that it is full of pins - and you run into
the room with your eyes closed then it is 100% your fault.

Could the language be defined differently to point out overflow 
erorrs?  Sure. 

Ignorance of the language spec is not an excuse.  Ignoring the
language spec is idiocy.

All in all though I do agree that it would be nice to be able
to catch overflow errors... and it would not be hard to extend
the language to do so.

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[David Botton]

Unless the language is marketed right :-)

David Botton

tmoran@bix.com wrote in message ...
>  A language that needs perfect programmers will have few programmers.

Re: Ada and Java. different behaviour. casting long to int problem.

[Keith Thompson]

D'Arcy Smith <nospam@itools.symantec.com> writes:
> If you're sent into a room that is full of pins sticking up from the
> floor - and you are told that it is full of pins - and you run into
> the room with your eyes closed then it is 100% your fault.

(I took the liberty of correcting some typos in the quoted text.)

If I hire someone to build me a house, and the living room is full of
pins sticking up from the floor -- and the builder clearly tells me
about this feature -- it's my fault if I run into the living room with
my eyes closed.  But I'm going to be a bit upset with the builder for
building it that way in the first place.

No programming language implementation can accurately and efficiently
model arithmetic on the full set of mathematical integers.  (If it
can't handle 10**(10**(10**100)), it's not modeling the full
mathematical set.)  So, some compromises are necessary, typically by
guaranteeing mathematical correctness only for a limited range (32
bits, 64 bits, whatever).  My favorite compromise is the one that
says:

    For any arithmetic operation on integers, you will get the
    mathematically correct result if it fits in the representation;
    otherwise, you will be clearly informed that the implementation
    was unable to do so (via an exception or some similar mechanism).

For most purposes, I believe this is *better* than a compromise that
says,

    For any arithmetic operation on integers, you will get the
    mathematically correct result if it fits in the representation;
    otherwise, you will get a mathematically incorrect (but perhaps
    well-defined) result, with no straightforward way to detect that
    it's mathematically incorrect.

This assumes, of course, that the abstraction you're trying to
(partially) model is the mathematical set of integers -- which it
usually is.  Some people have argued that wraparound semantics, if
they're well-defined, are as "correct" as anything else.  Sorry, but I
don't buy it.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

Re: Ada and Java. different behaviour. casting long to int problem.

[George W. Bayles]

D'Arcy Smith wrote:
[snip]
> > 'The result of an overflow isn't necessarily the wrong number' the bank
> > attorney replies. (flaged on the side by the bank top Java consultant ready
> > to supply more therotical evidence that supports such a statment).
> 
> I think you missed the implied - "depending on what the number
> is being used for".

That reminds me - using scaled integers to represent angles

  int theta = (int) MAX_INT*(theta_degrees/180.0); 

makes adding and subtracting angles much nicer because of the
wrap around! It is a feature of computer integers that they are
more like a compass than a ruler.

> Reading this thread... it would be nice to have a Java compiler
> that could generate checkes for overflows etc... perhaps a
> new keyword like they did with 'strictfp'.

This is something that would have to be added to the JVM 
specifications in order to do this efficiently - are there any
byte codes left?

Re: Ada and Java. different behaviour. casting long to int problem.

[Tucker Taft]

George W. Bayles wrote:
> 
> D'Arcy Smith wrote:
> [snip]
> > Could the language be defined differently to point out overflow
> > erorrs?  Sure.
> >
> 
> Perhaps you assume that all processors can automatically detect
> integer overflow in hardware? Any requirement wrt handling integer
> overflow you make in the language would incur severe performance
> penalties if the hardware doesn't support it.

This need not be true if the compiler does some basic 
range propagation, and only inserts overflow checking where necessary.
This is what our current Ada front end does, for what it is worth.

> It's a tradeoff - safety vs performance. How much safety are you
> losing though? Almost all the integer ops in a real program will
> never overflow. The few that can overflow can be readily checked

It is even better if the compiler determines where overflows are
possible using range propagation.  This way you get safety with
relatively modest overhead.  Also, even though hardware may not
signal overflow, it may reflect it in some kind of condition code.
The compiler can emit code to explicitly check the overflow condition
(when needed), whereas the programmer may not have any easy or
efficient way of writing such a check in the high-level language.

> int a,b,c;
> ....
> a = b + c;
> boolean overflowed = (c<0) ? (a>b) : (a<b);
> 
> [snip]

This whole thread seems to have confused the issue of language design
versus programmer skill.  Of course programmers should know the rules
of the language in which they program.  However, when it comes to
debating languages with respect to their "error-proneness," things
like the presence or absence of overflow detection becomes relevant.
Languages can be designed to help catch as many errors as possible,
as soon as possible (e.g. Ada), or they can be designed to provide direct,
unprotected access to the hardware with little or no concern for
maximizing the early detection of errors (e.g. C), or they can be
somewhere in the middle (e.g. Java).  

By retaining various error-prone characteristics of C/C++ (explicit 
"break" needed in switch, {} optional in if/else, ...) and even 
dropping some compile-time safety features (such as enum types), 
Java ends up in this intermediate position.  Presumably that is where
the Java designers wanted it to be.  It is just a bit inaccurate to then
call it a "very safe" language, when it clearly has made (especially 
compile-time) safety not as high a priority as it could have been. 

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada and Java. different behaviour. casting long to int problem.

[Mike Silva]

D'Arcy Smith wrote in message <3766D1CC.D712895E@itools.symantec.com>...
>
>If your sent into a room that is full of pins sticking up from the
>floow - and you are tole that it is full of pins - and you run into
>the room with your eyes closed then it is 100% your fault.


The situation is more analogous to taking a somebody who's driven for years,
and giving them a car which is designed such that at 60 mph it suddenly
shifts into reverse.  Below 60 mph everything is normal.  He's not an idiot,
and he's not incompetent, but no matter how hard he tries one day he's going
to forget and exceed 60 mph and whammo! (but hey, it was in the manual!)
Things designed to be used by humans should strive for "reasonable",
"expected" behavior whenever possible, and should notify the human when
that's not possible.

Mike

Re: Ada and Java. different behaviour. casting long to int problem.

[Fraser Wilson]

paene lacrimavi postquam "George W. Bayles" <georgeb@cajunbro.com> scripsit:

>Ada is a different language for different purposes. You don't 
>expect a compiled Ada program to run on anything but the 
>specific processor/system it was compiled for.

Well ... unless you use one of the Ada -> JVM compilers of course.

>Perhaps because the compiler is allowed to omit the array bounds 
>checking when it can prove it is safe - which in real programs is
>almost always the case. So, the performance penalty is minimized.

I can see this in for loops, but without a range subtype feature,
the possibilities for eliding this check in other situations seem
minimal.  Can you have arrays over an enumerated type in Java?
This also reduces runtime checks.

Fraser.
(change i's to y's for my real email address)

Re: Ada and Java. different behaviour. casting long to int problem.

[kirk]

In article <3767E8A2.EF1A0570@itools.symantec.com>, D'Arcy says...
 
>
>How long has C been around?  

And how long have we had buggy code?

>Its not like this is a new issue.

I agree. less than best language features are nothing new.
C/C++ as well as Java have them.

>And if you take the people using Java as a first language then
>there is no issue (they get told that this is the way it is).
>

you are repeating the same argument you said over and over, which is,
as long as it is documented, then it is OK.

The point of this discussion is beyond this simple view. It is about
one language aspect of java that many think is bad. replying by saying:
"but it is documented" is a cop-out argument in my opinion.

>for some things)... but get over it.

get over it?  we hear some people who want to use Java to build nuclear
plant control software with and to use Java to write the software that
will control systems that if failed will end up killing many people.

It is important that people know about the lack of safety in Java, so
not everyone get caught in the hype that is going around.

when my life is on line, I will not get over it.

it is too bad that the java designers did not take the time and go all 
the way and design a really good language, they seem to have started 
doing this, but the Sun marketing guys must have told to hurry up, and 
they sort of handed  over a half completed job of whatever they had 
completed at the time.

Kirk
 

Re: Ada and Java. different behaviour. casting long to int problem.

[Mark Hood]

Marin David Condic <condicma@bogon.pwfl.com> writes:
> 
> I'm of the opinion that if one wishes behavior different from that of
> "normal" arithmetic, then this should be specified by a type with
> special properties.
> [...]
> If one wants wraparound semantics, then perhaps there should be a special
> type to support that behavior - a la modular types in Ada.

I agree with this line of thinking, except that I think that the Java
primitive types ought to be left alone, and that specialized classes written
to more closely emulate the behavior of mathematical integers would be the
appropriate solution to these issues.

The whole point of Java primitive types such as int, long, and double is
that are *primitives*, ie, very close to the actual representations used by
the virtual machine.  They are exposed to the programmer because there are
some real advantages to working at that level, such as increased
performance.

It is of course completely feasible to wrap the primitive types in objects
which provide more safety and convenience for the programmer, and this is
exactly the intent of the Integer, Long, and Double classes.  These could
certainly be extended to check for overflows by any programmer who thinks
that would be desirable for the project at hand.

The argument has also been made that lack of overflow detection is as
onerous to quality code as the use of explicit pointers and the lack of
array bounds checking.  I disagree; the former has the possibility of
corrupting individual data values, while the latter carries the risk of
disrupting the integrity of the entire structure used to represent the data,
as well as the state of the virtual machine itself.  

Providing programmers access to primitive data types is a reasonable
compromise between safety and efficiency in my opinion.

-- Mark Hood

Re: Ada and Java. different behaviour. casting long to int problem.

[jerry]

Richard D Riehle <laoXhai@ix.netcom.com> wrote:

: Actually, U.S. banks do not use fixed point arithmetic.  They use
: decimal arithmetic.

Must be an ocupational hazzerd, since I keep doing this... When I use the
term fixed point in relation to either Ada or COBOL, I always mean decimal
fixed point. Sorry.

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Ada and Java. different behaviour. casting long to int problem.

[Samuel Mize]

In comp.lang.ada tmoran@bix.com wrote:
>   A language that needs perfect programmers will have few programmers.

False by observation, unfortunately.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Ada and Java. different behaviour. casting long to int problem.

[bill]

In article <yecyahk4ox7.fsf@king.cts.com>, Keith says...
 
>My favorite compromise is the one that
>says:
>
>    For any arithmetic operation on integers, you will get the
>    mathematically correct result if it fits in the representation;
>    otherwise, you will be clearly informed that the implementation
>    was unable to do so (via an exception or some similar mechanism).
>
>For most purposes, I believe this is *better* than a compromise that
>says,
>
>    For any arithmetic operation on integers, you will get the
>    mathematically correct result if it fits in the representation;
>    otherwise, you will get a mathematically incorrect (but perhaps
>    well-defined) result, with no straightforward way to detect that
>    it's mathematically incorrect.
>
>Some people have argued that wraparound semantics, if
>they're well-defined, are as "correct" as anything else.  Sorry, but I
>don't buy it.
>

Keith,

The above is an excellent summary of this thread.

I do not buy it either. no matter how many thousands of programmers go to
JavaOne each year :)

I think the bottom line of all of this, is that, it is OK if java
will add 2 positives number and give back a negative number as a
result, AS LONG AS the programmer has a way to be TOLD when this
does happen, or a way to tell the compiler/run-time: please tell
me when I make such a poopoo, or please do not tell me when I make
a poopoo as I know what I am doing.

Ada gives the programmer this choice. Java/C/C++ do NOT.

For this, as someone else already said, Java is no better than
C or C++ when those allow one to travel passed the array boundary
WITHOUT TELLING the programmer that they just did that.

In my eyes, there is absolutely no difference between the two situation,
travelling passed array boundary == adding 2 positive numbers and giving a 
negative number.

Why is it that java throws a run-time exception when one attempts to
write passed array boundary, but closes it eyes when an overflow occurs?

Based on this, I do not consider Java a safe language to use in applications
requiring very safe and predictable behaviour. 

Bill
 

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

D'Arcy Smith wrote:
> 
> If your sent into a room that is full of pins sticking up from the
> floow - and you are tole that it is full of pins - and you run into
> the room with your eyes closed then it is 100% your fault.
> 
> Could the language be defined differently to point out overflow
> erorrs?  Sure.
> 
> Ignorance of the language spec is not an excuse.  Ignoring the
> language spec is idiocy.
> 
At the risk of repeating myself... (what the heck? I like the sound of
my own voice! :-)

The assigning of 100% of the fault to me for ignoring the warning may be
an interesting point in assessing damages in a court of law. However, my
feet are still going to be bleeding rather badly and the whole
experience will have emotionally warped me for life. Assigning blame is
*not* going to make that go away. Hence my point is that issuing RTFM
warnings and calling the non-reader of the manual incompetent is an
exercise in futility. If a thing is dangerous and likely to cause
trouble because of ingenious idiots and the terminally incompetent, then
there should be designed into the process ways of preventing idiots from
cutting themselves with sharp objects or burning themselves with hot
coffee. You can't eliminate the idiots, but you can eliminate (or at
least mitigate) the opportunities they have to shoot themselves in the
foot.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[George W. Bayles]

D'Arcy Smith wrote:
[snip]
> Could the language be defined differently to point out overflow
> erorrs?  Sure.
>

Perhaps you assume that all processors can automatically detect
integer overflow in hardware? Any requirement wrt handling integer 
overflow you make in the language would incur severe performance 
penalties if the hardware doesn't support it.

It's a tradeoff - safety vs performance. How much safety are you 
losing though? Almost all the integer ops in a real program will
never overflow. The few that can overflow can be readily checked

int a,b,c;
....
a = b + c;
boolean overflowed = (c<0) ? (a>b) : (a<b);

[snip]

Re: Ada and Java. different behaviour. casting long to int problem.

[George W. Bayles]

bill@world.nospam.com wrote:
[snip]
> 
> Ada gives the programmer this choice. Java/C/C++ do NOT.
>

Ada is a different language for different purposes. You don't 
expect a compiled Ada program to run on anything but the 
specific processor/system it was compiled for.
 
[snip]
> 
> Why is it that java throws a run-time exception when one attempts to
> write passed array boundary, but closes it eyes when an overflow 
> occurs?
>

Perhaps because the compiler is allowed to omit the array bounds 
checking when it can prove it is safe - which in real programs is
almost always the case. So, the performance penalty is minimized.

> Based on this, I do not consider Java a safe language to use in 
> applications requiring very safe and predictable behaviour.
> 

So use Ada for these!

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

Keith Thompson wrote:
> 
> D'Arcy Smith <nospam@itools.symantec.com> writes:
> > If you're sent into a room that is full of pins sticking up from the
> > floor - and you are told that it is full of pins - and you run into
> > the room with your eyes closed then it is 100% your fault.

> (I took the liberty of correcting some typos in the quoted text.)

But I took so long to get them in... :-)
I am probably the worlds worst person when it comes to typing.
 

> If I hire someone to build me a house, and the living room is full of
> pins sticking up from the floor -- and the builder clearly tells me
> about this feature -- it's my fault if I run into the living room with
> my eyes closed.  But I'm going to be a bit upset with the builder for
> building it that way in the first place.

Sure you can be upset... I don't disagree that checking for overflows
would be nice to have (perhaps even necessary)... but to say that 
it is the fault of the designers that people do not follow the
spec is silly.

 
>     For any arithmetic operation on integers, you will get the
>     mathematically correct result if it fits in the representation;
>     otherwise, you will get a mathematically incorrect (but perhaps
>     well-defined) result, with no straightforward way to detect that
>     it's mathematically incorrect.

I don;t care if the spec says it can format my hard-drive if the
thing overflows... :-)  If it says that and some programmer does
it then the fault lies 100% with the programmer.


> This assumes, of course, that the abstraction you're trying to
> (partially) model is the mathematical set of integers -- which it
> usually is.  Some people have argued that wraparound semantics, if
> they're well-defined, are as "correct" as anything else.  Sorry, but I
> don't buy it.

Whatever... it is in the spec so there is no excuse to plead 
ignorance about it.

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[Richard D Riehle]

In article <FDDxsM.B9@stuyts.nl>,
	jerry@jvdsys.stuyts.nl wrote:

>Of course, there was no overflow but an error. Banks use fixed point 
>arithmatic. It is actually a reason why PL/I is still in use, Cobol,
>like Ada, garantees 18 digits accuracy and that sometimes is not
>enough. IBM's PL/I compiler offers 22 digit accuracy for it's fixed point
>arithmatic.

Actually, U.S. banks do not use fixed point arithmetic.  They use
decimal arithmetic.  This is one reason COBOL is preferred over 
languages that do not have inherent support for decimal data types.
Ada has added decimal type capability with,
 
        type Yen is delta 0.01 digits 15;

There is no need for any kind of type casting.  

It should be of interest to note that Ada and COBOL are among the
few languages with direct support for decimal data types. In this
regard, Ada and COBOL are superior to C++, Eiffel, Java, Modula-3, 
etc, which  all require a decimal type class to make this work.
Unfortunately, this is one of those cases where defining a class is 
not as effective as intrinsic language support.  

Even better, with Ada we can easily express the proper relationships
and operations for accounting using the decimal fraction data type.

            package Money is
               type Dollars is delta 0.0001 digits 15;
               Money_Error : exception;
               ...
            end Money;

followed by an abstract type that can be used as the root for derivations
of asset, liability, equity, expense, and revenue account types.  For
example, a debit behaves differently for an asset than for a liability.

            package Money.Accounting is
               type Account_Type is abstract tagged private;
               procedure Debit
                            (Account : in out Account;
                             Amount  : in     Dollars) is abstract;
               procedure Credit 
                            (Account : in out Account;
                             Amount  : in     Dollars) is abstract;
            private
               type Account_Type is abstract tagged record
                  Amount : Dollars := 0.0;
                  ...
               end record;
            end Money.Accounting;
            
Decimal types is one of those cases where Ada has excellent potential 
for simple and direct solutions to a set of problems that is likely 
to be more complex in a language such as C++ or Java.  

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: Ada and Java. different behaviour. casting long to int problem.

[Richard D Riehle]

In article <P4B93.340$07.28478@typhoon-sf.snfc21.pbi.net>,
	tmoran@bix.com wrote:

>>then it becomes the resposibility of the programmer to understand this,
>>and a programmer that produces a program that fails to check everywhere
>>for this, is an incompetent programmer.
>  A language that needs perfect programmers will have few programmers.

  Tom, 

  I would rather think that a language that requires perfect programmers
  will  result in more imperfect programs.  There is certainly an 
  abundance of C++ and Java programmers, but a scarcity of quality
  programs.  

  The original posting suggesting the problem of the "incompetent 
  programmer" fails to recognize that incompetence is a variable
  characteristic.  All of us (speaking especially for myself) have
  been guilty of incompetence at one time or another in our software
  career.  

  Someone once said that locks on doors are to "keep honest people 
  honest."  A language design such as that enjoyed by Ada programmers
  helps keep competent programmers competent.  The perennially
  incompetent programmer will be incompetent in any language.  

  Richard Riehle
  richard@adaworks.com
  http://www.adaworks.com

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

"George W. Bayles" wrote:

> > Could the language be defined differently to point out overflow
> > erorrs?  Sure.

> Perhaps you assume that all processors can automatically detect
> integer overflow in hardware? Any requirement wrt handling integer
> overflow you make in the language would incur severe performance
> penalties if the hardware doesn't support it.

No I don't assume it - I was thinking that it could be an optional
operation that the compiler could do... but thinking more about it
that belongs at the VM level.

If it is optional (like "strictfp") then people at least know that
there will be a performance penalty that changes depending on the VM 
implementation.


> It's a tradeoff - safety vs performance. How much safety are you
> losing though? Almost all the integer ops in a real program will
> never overflow. The few that can overflow can be readily checked

> int a,b,c;
> ....
> a = b + c;
> boolean overflowed = (c<0) ? (a>b) : (a<b);

And you could provide a class do that (it wouldn't be as nice
and nobody start on overloaded operators!):

   // just using what you did above
   public class SafeMath
   {
       public int add(int a, int b) 
       {
           int result;

           result = b + c;
           
           if(b < 0) ? (result > a) : (result < a)
           {
               // a runtime exception.
               throw new UverflowException(a + " + " + b);   
           }
       }

       etc...
   }

   ...
   try
   {
       SafeMath.add(5, 6);
   }
   catch(OverflowException ex)
   {
   }
   ...

The try/catch are optional.

This solution is nice because it requres no language change and is
easy to implement.  The downside is that there is a performance hit 
regardless of your hardware... it also doesn't look real pretty :-)

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

"George W. Bayles" wrote:

> > Could the language be defined differently to point out overflow
> > erorrs?  Sure.

> Perhaps you assume that all processors can automatically detect
> integer overflow in hardware? Any requirement wrt handling integer
> overflow you make in the language would incur severe performance
> penalties if the hardware doesn't support it.

No I don't assume it - I was thinking that it could be an optional
operation that the compiler could do... but thinking more about it
that belongs at the VM level.

If it is optional (like "strictfp") then people at least know that
there will be a performance penalty that changes depending on the VM 
implementation.


> It's a tradeoff - safety vs performance. How much safety are you
> losing though? Almost all the integer ops in a real program will
> never overflow. The few that can overflow can be readily checked

> int a,b,c;
> ....
> a = b + c;
> boolean overflowed = (c<0) ? (a>b) : (a<b);

And you could provide a class do that (it wouldn't be as nice
and nobody start on overloaded operators!):

   // just using what you did above
   public class SafeMath
   {
       public int add(int a, int b) 
       {
           int result;

           result = b + c;
           
           if(b < 0) ? (result > a) : (result < a)
           {
               // a runtime exception.
               throw new OverflowException(a + " + " + b);   
           }
       }

       etc...
   }

   ...
   try
   {
       SafeMath.add(5, 6);
   }
   catch(OverflowException ex)
   {
   }
   ...

The try/catch are optional.

This solution is nice because it requres no language change and is
easy to implement.  The downside is that there is a performance hit 
regardless of your hardware... it also doesn't look real pretty :-)

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

"George W. Bayles" wrote:

> This is something that would have to be added to the JVM
> specifications in order to do this efficiently - are there any
> byte codes left?

Yes there are bytecodes left... looking at the 1.2 VM pec there
are free bytecodes from and including 0xca (203) to 0xfd (252).  

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

Mike Silva wrote:

> D'Arcy Smith wrote in message <3766D1CC.D712895E@itools.symantec.com>...

> >If your sent into a room that is full of pins sticking up from the
> >floow - and you are tole that it is full of pins - and you run into
> >the room with your eyes closed then it is 100% your fault.

> The situation is more analogous to taking a somebody who's driven for years,
> and giving them a car which is designed such that at 60 mph it suddenly
> shifts into reverse.  

I.m going with your talking about people going from some language
(say Ada) to another (say Java)... 

I'd say it is more like sending a US driver to England...


> Below 60 mph everything is normal.  He's not an idiot,
> and he's not incompetent, but no matter how hard he tries one day he's going
> to forget and exceed 60 mph and whammo! (but hey, it was in the manual!)

Hey less stupid people, I'm all for it :-) (joke! - well I am not for 
stupid people... but it might include me... who knows :-)



> Things designed to be used by humans should strive for "reasonable",
> "expected" behavior whenever possible, and should notify the human when
> that's not possible.

How long has C been around?  Its not like this is a new issue.
And if you take the people using Java as a first language then
there is no issue (they get told that this is the way it is).

When you switch from one language to another, or just compare
languages, your going to think that the new language does some
lame assed things... I felt that way about Java (I still do
for some things)... but get over it.

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

kirk@spam_free wrote:

> In article <3767E8A2.EF1A0570@itools.symantec.com>, D'Arcy says...

> >How long has C been around?

> And how long have we had buggy code?

And how wide a margine can you miss my point by?

"> Things designed to be used by humans should strive for "reasonable",
 > "expected" behavior whenever possible, and should notify the human
when
 > that's not possible."

If you come from C the expected behaviour is exactly what
Java does.  You may not agree with the behaviour but it
is completely expected given what influenced Java.

Perhaps if you look at it like this:  Java is not an end.

We had C... good.  C++ came along and removed some of the "bad"
things - use const instead of #define etc... Java came along
and removed some additional "bad" things from C and then removed
some "bad" things from C++.  Java also did some silly things.
One day a language is going to come along and take parts of
Java and we will wind up with something that is "better".

Please note the use of ""s all over there.


> >Its not like this is a new issue.

> I agree. less than best language features are nothing new.
> C/C++ as well as Java have them.

I'm sure Ada has some silly things as well... I don't know what
they are since I've never used it.


> >And if you take the people using Java as a first language then
> >there is no issue (they get told that this is the way it is).

> you are repeating the same argument you said over and over, which is,
> as long as it is documented, then it is OK.

No I never said that.  I said (or implied) as long as it is documented 
and people screw up then it is THEIR fault not the fault of the
language.


> The point of this discussion is beyond this simple view. It is about
> one language aspect of java that many think is bad. replying by saying:
> "but it is documented" is a cop-out argument in my opinion.

I've agreed that it probably would be better to handle it in a
different way.  It doesn't get over it.

 
> >for some things)... but get over it.


> get over it?  we hear some people who want to use Java to build nuclear
> plant control software with and to use Java to write the software that
> will control systems that if failed will end up killing many people.

Ada software has _never_ failed?  Ada software has never had programmers
who make mistakes.  Cool.  Good for you.

Now if you say Ada offers features to avoid certain types of mistakes
then I'll agree.

Can Java programmers do something to work around the fact that the
language doens't support overflow exceptions?  Sure I've already 
given a code snippet.  Makes to code slower and move verbose but
it does what you want (or at least is the basis for that).

Would Java be more robust if it handled overlows - sure.


> It is important that people know about the lack of safety in Java, so
> not everyone get caught in the hype that is going around.

Ummm... if people don;t read the language spec then that is their
problem (and yes I have read the C/C++/Java language specs).
Now in the case of a nuclear power plant (which unless the Java
license has changed you can't use Java for IIRC) then yes it is
all of our problem.  But I am sure that someone writing bad Ada
code could cause just as many problems (just different ones :-)

 
> when my life is on line, I will not get over it.

Again - there has _never_ been a bug in any Ada software?


> it is too bad that the java designers did not take the time and go all
> the way and design a really good language, they seem to have started
> doing this, but the Sun marketing guys must have told to hurry up, and
> they sort of handed  over a half completed job of whatever they had
> completed at the time.

I'll agree with that - but I really doubt that they would have
made the Overflow change that you are wanting.

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[Hyman Rosen]

kirk@spam_free writes:
> get over it?  we hear some people who want to use Java to build nuclear
> plant control software with and to use Java to write the software that
> will control systems that if failed will end up killing many people.

Looks like it's time to mention again that an unhandled exception
raised by conversion overflow caused the Ariane 5 rocket to go off
course, resulting in its destruction.

Exceptions don't make a language safe - they just make it more
likely that bugs will be caught in testing. That's not bad, but
it's also not a panacea.

Re: Ada and Java. different behaviour. casting long to int problem.

[Aidan Skinner]

On Wed, 16 Jun 1999 11:49:27 -0500, George W. Bayles
<georgeb@cajunbro.com> wrote:

>That reminds me - using scaled integers to represent angles
>
>  int theta = (int) MAX_INT*(theta_degrees/180.0); 
>
>makes adding and subtracting angles much nicer because of the
>wrap around! It is a feature of computer integers that they are

But in Ada you could just use a type similar to this:

type degree is mod 360;

theta : degree := 0;

to achieve the same nice wrap around effect with less convulated code.

It's one of the things I really like about Ada: you can generally
achieve the semantics you want easily with a little bit of knowledge.

- Aidan (read the RM, know the RM. The RM is your friend. Trust the RM)
-- 
http://www.skinner.demon.co.uk/aidan/
Horses for courses, tac-nukes to be sure.

Re: Ada and Java. different behaviour. casting long to int problem.

[Aidan Skinner]

On Wed, 16 Jun 1999 11:26:42 -0500, George W. Bayles
<georgeb@cajunbro.com> wrote: 

>Ada is a different language for different purposes. You don't 
>expect a compiled Ada program to run on anything but the 
>specific processor/system it was compiled for.

Depends, JGnat is apparently coming along nicely... ;)

Besides, I fail to see what wrap-around versus exception semantics for
integer overflow has to do with the ability to compile to bytecode.

- Aidan
-- 
http://www.skinner.demon.co.uk/aidan/
Horses for courses, tac-nukes to be sure.

Re: Ada and Java. different behaviour. casting long to int problem.

[Markus Kuhn]

Mark Hood <hood@eng.sun.com> writes:
|> > In Java, nothing happens, and life goes on and the final number is wrong,
|> > but no one really knows it is wrong, or may be someone will notice it is
|> > wrong.
|> 
|> I think the point is that the result of an overflow isn't necessarily the
|> wrong number.  
|> 
|> For example, one could be working with data that needs to be expressed in
|> some signed 16-bit quantized space, and wish to encode consecutive elements
|> in that space as deltas from previous values in a streamed fashion.  In that
|> case the overflow semantics are essential, since otherwise it wouldn't be
|> possible to express the delta between -30000 and +30000 in 16 bits.
|> 
|> The example isn't contrived; it's common in compression algorithms.  My
|> impression is that Ada is oriented toward numerical applications, and so the
|> overflow checks are probably appropriate.  It would certainly be
|> inconvenient for many Java applications if the defined behavior of signed
|> 2's complement integers were thwarted.

Just for the record: Ada95 does have so-called "modular integer
types" such as Unsigned_8, Unsigned_64, etc.  These do overflow
without raising any exception, for exactly the applications that
you mentioned, just like the corresponding unsigned int types
in C.

If X is a modular type, then you always get X'Last + 1 = 0 in
Ada95. (X'Last is just the Ada notation for the highest possible
value that variable X can possibly have, e.g. 255 for X : Unsigned_8).

Modular integer types were one of the many important improvements
that were made to Ada in the 1995 complete revision of the language,
and they are invaluable for high-performance coding of many signal
processing algorithms.

Your impression that Ada is "oriented toward numerical applications"
is not true any more for the modern Ada95 language that the GNAT compiler
implements. Ada95 is in my experience at least as well suited for
high-performance bit fiddling in data compression, data encryption,
and signal processing algorithms as C is. But in addition to C,
you get the safety and comfort features of Java as well.

For me, Ada95 combines the best of both the C and the Java world:
High performance, low-level access as well as type safety, and comfort.
It is amazing how underhyped this equally young language is
compared to Java in the trade press. But then, who asks the trade
press ...

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Ada and Java. different behaviour. casting long to int problem.

[Markus Kuhn]

Hyman Rosen <hymie@prolifics.com> writes:
|> Looks like it's time to mention again that an unhandled exception
|> raised by conversion overflow caused the Ariane 5 rocket to go off
|> course, resulting in its destruction.
|> 
|> Exceptions don't make a language safe - they just make it more
|> likely that bugs will be caught in testing. That's not bad, but
|> it's also not a panacea.

The problem in the Ariane 5 maiden flight failure was certainly that
the relevant subsystem has never been fully tested with the
parameters of the new rocket, and not that it was programmed
in Ada. Actually, the example shows well, that if it HAD it been
tested, the exception that has occured would have pointed immediately
to the right location of the problem, instead of just to "something
is going wrong here".

It is not Ada's fault, that the first full test of the gyro system
happened only during the maiden flight.

Anyway, the report is certianly worth reading:

  http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Ada and Java. different behaviour. casting long to int problem.

[Markus Kuhn]

D'Arcy Smith <nospam@itools.symantec.com> writes:
|> I'm sure Ada has some silly things as well... I don't know what
|> they are since I've never used it.

Actually, they are in my opinion pretty rare now. Ada83 was a clean
design from scratch, which was very neat but also had quite a few important
bits missing (most notable object inheritance) and had a few rather
strange limitations. These however were thoroughly fixed when Ada was
completely revised in 1995 from ground up, building on over a decade of
experience with the first Ada language. The new second Ada language is a
real beauty now IMHO and we finally have also free and low-cost
high-quality development environments such as the GNU Ada95 compiler
available for it. Definitely worth having a look at, especially if
Java got you interested in new modern languages, but did not fully
live up to your expectations.

I consider Ada95 and Java to be the by far most interesting
production programming languages around in 1999 (as opposed to
experimental academic languages). They do target different application
areas however. While Java was designed for maximum portability and
GUI-oriented application software that is not extremely time critical,
Ada95 is more a broad systems-programming language that is
well suited for both portable application programming as well as
low-level bit fiddling, real-time signals processing, high performance
computing, and embedded applications with strict safety and
resource requirements, which were so far more the domain of C.

|> Ada software has _never_ failed?

Good Lord, of course not. You can screw up in Ada just as much as
you can screw up in any language. The nice thing about Ada is just
that the language requires compilers to immediately spot many
dubious situations for which you would have to buy very expensive and
still less reliable tools to detect them in other languages. An
experienced Ada programmer can use Ada's powerful subtype system to
proof various properties of code for which in other langauges
you would need very expensive dataflow analysis and verification
tools. This has made Ada95 or Ada subsets such as SPARK the languages
of choice in safety critical applications, such as military
systems and avionics, but also more recently in quite some financial
applications.

Ada just supports you well if you want to write very carefully
engineered and highly maintainable code. It certainly does not
force you to do so. No language could.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Ada and Java. different behaviour. casting long to int problem.

[Samuel Mize]

Marin David Condic <condicma@bogon.pwfl.com> wrote:
> Jean-Pierre Rosen wrote:
...
>> You can't blame the language for doing exactly what was in the
>> specification; the specifications were wrong.
...
> IMHO, the *real* problem was not
> anything to do with language features - it was a fundamental management
> problem.

All true.

However, the original poster's point was simply that raising an
exception on overflow won't necessarily save the day, or result
in a safer program.

Unfortunately, referring to Ariane on comp.lang.ada is like referring
to "Hitler" in other news groups...

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert I. Eachus]

Marin David Condic wrote:
>                                 If one wants wraparound semantics, then
> perhaps there should be a special type to support that behavior - a la
> modular types in Ada. (Although these don't contain negative numbers and
> that may be a requirement.) In some cases, saturation semantics are a
> good thing, but again, this is not the "normal" understanding of
> arithmetic and therefore should be supported by a special type.
 
      Interesting question, but far from this topic...  If you want a
type with negative numbers that wraps around in Ada, how do you do it? 
Pragma Suppress is the easiest solution, but it is not guarenteed to
work portably, or even to work at all.  You can derive a type from a
modular type and override the comparison operators, etc.  This is
probably the best route.  The cleanest way from a users point of view is
probably to derive from Integer and override the arithmetic operations. 
This does have the problem with reemergence of the predefined operators
(see RM 12.5(8)) in a generic when one of these types is passed as a
generic formal integer type rather than a generic formal derived type.  
However, I think that this is probably the right behavior--let the
author of the generic worry about overflow inside the generic.  If you
want to use the redefined operators, you can always pass them as genric
formal subprograms.

      To bring this discussion back on topic, probably the best solution
for compilers that want to interface cleanly with Java, is to provide an
Interfaces.Java package, with an explicitly non-standard integer type
that can be converted to and from an Ada integer type.

-- 

                                        Robert I. Eachus

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

Re: Ada and Java. different behaviour. casting long to int problem.

[john]

In article <7kbbk8$hej$2@pegasus.csx.cam.ac.uk>, mgk25@cl.cam.ac.uk says...
 
>
>I consider Ada95 and Java to be the by far most interesting
>production programming languages around in 1999 (as opposed to
>experimental academic languages). 

It seems though that Java has by far the more complete standard
library. This fact, many would consider, is much more important
in the commerical world, than considerations related to basic
language issues.

Success of a computer language seems to depend more on the availability
of standard and well tested libraries that can be very easily used
by the language in question. With Java, we have libraries that comes
bundled with the Sun JDK that makes building applications in Java in 
many domain just a matter of block building.

You can not do that in C or Ada or even C++ C++.  Even C++ newset library
is a child play in terms of functionalities provided compared to what 
the JDK contains. Check the JDK 2.0 platform and see what kind of
packages come with it. It is an amazing collection.

So, unless Ada can come up with a set of libraries that come bundled
with your GNAT compiler and ready to use and can match the
functionalitites of those provided by Java, I am afraid Ada will
not have a chance of attracting programmers away from Java or away
from C++.

Even the C++ programmers now are asking to port the Java JDK
libraries to C++ !

cheers,
John.
 

Re: Ada and Java. different behaviour. casting long to int problem.

[George W. Bayles]

Tucker Taft wrote:
> 
[snip]
> The compiler can emit code to explicitly check the overflow condition
> (when needed), whereas the programmer may not have any easy or
> efficient way of writing such a check in the high-level language.
> 
> > int a,b,c;
> > ....
> > a = b + c;
> > boolean overflowed = (c<0) ? (a>b) : (a<b);
> >
> > [snip]
>
Huh? This high level overflow check may not be terribly efficient but
it is easy enough.

[snip]

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert I. Eachus]

Hyman Rosen wrote:
 
> Looks like it's time to mention again that an unhandled exception
> raised by conversion overflow caused the Ariane 5 rocket to go off
> course, resulting in its destruction.
 
    It may be time again to point out that that the software behaved
exactly as it was intended to behave.  However, it was designed for the
Ariane 4 and used succesfully in numerous launches, including one where
the specific feature that killed the first Ariane 5 was used.  To "save"
money, it was decided to use the software unchanged in the Araine 5 and
never check it against the Ariane 5 requirements, or do any ground
testing.  (To be fair, a simulation environment for the flight control
software was originally planed, but it was cut for cost and schedule
reasons.)

    Behavior that indicated a major malfunction on Ariane 4 was normal
and expected on the Ariane 5.  Software reuse can save money, but you
still have to ensure somehow that the software meets the new
requirements.  The way that the Ariane 5 project chose to do that was
probably the most expensive way possible.

    I'm not saying this to "defend" Ada.  I'm saying it because there
are circumstances where the software developers have no chance to get it
right because of management blunders, and it is wrong to blame this
either on the programmers or the programming language.  If someone buys
navigation software designed for cargo ships, then installs it in an
airplane, that nifty automatic grounding avoidance feature is going to
cause real problems.  But that is not the software developers fault. 
-- 

                                        Robert I. Eachus

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

Re: Ada and Java. different behaviour. casting long to int problem.

[Ed Falis]

On 17 Jun 1999 11:39:46 -0700, john@smith.nospam.com wrote:

> 
> So, unless Ada can come up with a set of libraries that come bundled
> with your GNAT compiler and ready to use and can match the
> functionalitites of those provided by Java, I am afraid Ada will
> not have a chance of attracting programmers away from Java or away
> from C++.
> 
> Even the C++ programmers now are asking to port the Java JDK
> libraries to C++ !

Well, JDK 1.1 has been available for JVM targeted Ada applications for what, 2 years now?  It's available for Ada native applications using 
AdaJNI for compilers on Windows and various UNIXes.   And I've generated a Java 2 binding for AdaJNI as well, which'll be publicly 
available in the not too distant.  Only drawback is that you have to fire up a JVM to run the stuff.  But that doesn't bother people using JAva, 
so ...

- Ed

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Samuel Mize wrote:
> 
> All true.
> 
> However, the original poster's point was simply that raising an
> exception on overflow won't necessarily save the day, or result
> in a safer program.
> 
Point taken. I don't think Ariane 5 was an issue of exception raising
since they had removed the checks. My recollection was that it had to do
with an overflow interrupt which caused the channel to shut down and
transfer control to the other side (which was what the design called
for.) Still, an interrupt or an exception are similar in intention: Stop
doing what you are doing and handle an unusual condition.

With the Ariane 5 disaster, the day *might* have been saved if the
arithmetic saturated rather than overflowed or wrapped around. Just
another example of how a specialized type with specialized behavior may
be better in some conditions.


> Unfortunately, referring to Ariane on comp.lang.ada is like referring
> to "Hitler" in other news groups...
> 
Tell me about it! ;-) I'm afraid I get a bit hypersensitive to the issue
because at the time Ariane 5 happened I was building a rocket engine
control based on the same processor and programmed in the same language.
As a result, there were way too many people wanting to know if we had
the same sort of problem. It was *not* one of the more pleasant
experiences in my software engineering career.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Robert I. Eachus wrote:
> 
>       Interesting question, but far from this topic...  If you want a
> type with negative numbers that wraps around in Ada, how do you do it?
> Pragma Suppress is the easiest solution, but it is not guarenteed to
> work portably, or even to work at all.  You can derive a type from a
> modular type and override the comparison operators, etc.  This is
> probably the best route.  The cleanest way from a users point of view is
> probably to derive from Integer and override the arithmetic operations.
> This does have the problem with reemergence of the predefined operators
> (see RM 12.5(8)) in a generic when one of these types is passed as a
> generic formal integer type rather than a generic formal derived type.
> However, I think that this is probably the right behavior--let the
> author of the generic worry about overflow inside the generic.  If you
> want to use the redefined operators, you can always pass them as genric
> formal subprograms.
> 
Are you sure you would want to "derive* a type? Or just declare your own
integer type? Obviously, you override the operators - most likely
dipping into assembler to implement them. Still, we've attempted similar
things and sometimes found it very hard, if not impossible, to implement
because of processor architecture/language assumption issues. By that, I
mean the nature of the interrupts which may/may not be enabled and what
use the rest of the system wants to make of them. The problem is not
necessarily one of being able to get there, but getting there without
severe time penalties.

>       To bring this discussion back on topic, probably the best solution
> for compilers that want to interface cleanly with Java, is to provide an
> Interfaces.Java package, with an explicitly non-standard integer type
> that can be converted to and from an Ada integer type.
> 
Clearly, that is what Ada did with C to support C's data types. Can you
create an "Interfaces.Java" without being a compiler? I know GNAT
complains if you try to extend anything that starts with "Ada." - do
similar restrictions apply?

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Hyman Rosen wrote:
> All I'm saying is that exceptions are better than wraparound only in
> the test/debug environment. Out in the field, especially when the
> software must work the first time, exceptions are probably going to be
> more harmful than wraparound, because the former causes a large part
> of the code to abruptly abort, while the latter causes a local
> error. In many cases, the local error just causes a glitch but the
> system as a whole can continue working.

Well.... Let's try something a little more specific: Exceptions vs
wraparound vs saturation and which is "better in the field" is going to
depend a whole lot on which field. For example, in most commercial data
processing applications, an exception is far superior to any other
semantics because the problem of failing the program is not nearly so
costly as the problem of putting a wrong balance in someone's checking
account. Whereas, for the kind of embedded control that I work with,
saturation is far superior to an exception and way far better than
wraparound. If you command an LVDT to go "too far" and the number
saturates, you just drive to the limit of the device. If you raise an
exception, then at least the control may go to fail-fixed or fail-safe
and things may work out all right. However, if you wraparound, you're
going to instantaneously command the device in the exact opposite
direction at full power - an event that has a bad habit of resulting in
energetic disassembly.

So I think the correct answer is that a language which aspires to
address a wide variety of problem domains should make it possible
through classes of types to pick the semantics appropriate for the
situation. Ada kind of does it, but IMHO could benefit from numeric
classes with other defined behaviors. (Most notably, saturation would be
very beneficial to our domain, and probably to a lot of others.)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Tucker Taft]

George W. Bayles wrote:
> 
> Tucker Taft wrote:
> >
> [snip]
> > The compiler can emit code to explicitly check the overflow condition
> > (when needed), whereas the programmer may not have any easy or
> > efficient way of writing such a check in the high-level language.
> >
> > > int a,b,c;
> > > ....
> > > a = b + c;
> > > boolean overflowed = (c<0) ? (a>b) : (a<b);
> > >
> > > [snip]
> >
> Huh? This high level overflow check may not be terribly efficient but
> it is easy enough.

It is straightforward if all you have is an assignment with
a single operation.  However, potentially-overflowing arithmetic
can occur anywhere, including in things like "i++" where significant
rewriting would be required to insert a check.
So that is what I meant by saying it was not "easy."
I presume you agree with the efficiency issue.

> 
> [snip]

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada and Java. different behaviour. casting long to int problem.

[Chris Dollin]

[I've [tried to] set followups to remove comp.lang.ada]

"George W. Bayles" wrote:

[wrt Java throwing an exception on array-bound violation]

> Perhaps because the compiler is allowed to omit the array bounds
> checking when it can prove it is safe - which in real programs is
> almost always the case. So, the performance penalty is minimized.

The Java *compiler* [ie the source-to-bytecode translator] can't
do this, because there's no unchecked-array-indexing instructions
in the bytecode set.

And if it *could*, the verifier would have to be able to prove
the same things that *that* compiler did in order to accept the
code; which may be infeasible [eg take too long].

A JIT or other bytecode-to-something-faster translator could
do it, of course.

-- 
Exceptional Hedgehog

Re: Ada and Java. different behaviour. casting long to int problem.

[bob]

In article <t7bteed21s.fsf@calumny.jyacc.com>, Hyman says...
>
 
>
>All I'm saying is that exceptions are better than wraparound only in
>the test/debug environment. Out in the field, especially when the
>software must work the first time, exceptions are probably going to be
>more harmful than wraparound, because the former causes a large part
>of the code to abruptly abort, while the latter causes a local
>error. In many cases, the local error just causes a glitch but the
>system as a whole can continue working.

This logic does not make sense at all.

When an exception happen, you catch it, and then you can simply
ignore it if that is really what you want to do depending on the
exception, or you print some error message and also ignore it,
or you can throw it again.  The point is, raising an exception and 
handling it, are 2 different issues. So your point about the program 
abruptly aborting do not make sense.

In Java, exceptions are used so much, that it is hard to find 10 lines
of java code without a try/catch in them somehwhere. 

And when you talk about a 'local error', I think you have you dark glasses
on. Do you know that a number being one bit off, can end up causing 
the most major problems in the system down the stream? you'll end up 
with small bad data, traveling across the program, generating more bad 
data every where as it feeds more functions, which can end up with 
much more damage across all parts of the system.

regards,
Bob

Re: Ada and Java. different behaviour. casting long to int problem.

[bob]

In article <37696EAB.E2226E2A@averstar.com>, Tucker says...
>
 
>> Huh? This high level overflow check may not be terribly efficient but
>> it is easy enough.
>
>It is straightforward if all you have is an assignment with
>a single operation.  However, potentially-overflowing arithmetic
>can occur anywhere, including in things like "i++" where significant
>rewriting would be required to insert a check.

Not only that, what about intermmediate generated results?

as in 

A = B + ( C + D)

the result of C+D must be stored somewhere in a register or wherever the
compiler decides. (I am assuming no optimization, and this is just
an example).

So, if the programmer needs to check for oveflow by hand (which is 
a silly solution if I heared of one), then the programmer needs 
to start writing the above like this:

i = C + D
// add code to check that i not overflow
A = B + i
//add code to check that A did not overflow.


Now, with a language that enable expceptions on overflow, I can write

-------------------------------
try
{
  A = B + ( C + D)
}catch(OverFLowException e)
{
   print("hay, watch out, you have a bug on line " + r.printLineNumber()");
   print("please fix your data type, or do something about it");
   // here I can either throw() the expection again, or ignore it
   // but at least I knew about it
}
-----------------------------------
 

bob
 

Re: Ada and Java. different behaviour. casting long to int problem.

[Larry Kilgallen]

In article <3767CDFC.798BBB23@cajunbro.com>, "George W. Bayles" <georgeb@cajunbro.com> writes:
> D'Arcy Smith wrote:
> [snip]
>> Could the language be defined differently to point out overflow
>> erorrs?  Sure.
>>
> 
> Perhaps you assume that all processors can automatically detect
> integer overflow in hardware? Any requirement wrt handling integer 
> overflow you make in the language would incur severe performance 
> penalties if the hardware doesn't support it.

Java effectively presumes that all processors have hardware support
for a particular scheme of floating point.  DEC have received strong
customer feedback to get Java on VAX/VMS, but have steadfastly declined
because emulating IEEE floating point on non-IEEE floating point hardware
gave horrible performance.

Larry Kilgallen

Re: Ada and Java. different behaviour. casting long to int problem.

[Matthew Heaney]

On 16 Jun 1999 11:49, "George W. Bayles" <georgeb@cajunbro.com> wrote:

> That reminds me - using scaled integers to represent angles
> 
>   int theta = (int) MAX_INT*(theta_degrees/180.0); 
> 
> makes adding and subtracting angles much nicer because of the wrap
> around! It is a feature of computer integers that they are more like a
> compass than a ruler.

You can do this in Ada already:

  with System;
  package Angle_Types is

    type Angle_In_Deg_Type_Base is
      delta 1024.0 * System.Fine_Delta
      range -1024.0 .. 1024.0;

    for Angle_In_Deg_Type_Base'Small use
      1024.0 * System.Fine_Delta;

    subtype Angle_In_Deg_Type is
      Angle_In_Deg_Type_Base
      range 0.0 .. Angle_In_Deg_Type_Base'Pred (360.0);

    function "+" (L, R : Angle_In_Deg_Type)
      return Angle_In_Deg_Type;

    function "-" (L, R : Angle_In_Deg_Type)
      return Angle_In_Deg_Type;

    <other ops>

  end Angle_Types;


The addition and substraction operators are defined to have wrap-around
semantics.

This captures the angle abstraction perfectly, and we don't have to go
mucking around with hacks like "scaled integers."

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Jean-Pierre Rosen wrote:
> Please read the report.
> The Ariane 501 failure was caused by the *removal* of a necessary
> check.
> Ada then diagnosed correctly the error, and did what the
> specifications required it to do in this case: it made a memory dump
> which was interpreted by the flight computer as positionnal data.
> You can't blame the language for doing exactly what was in the
> specification; the specifications were wrong.
> Of course, without overflow checking, you would'nt have triggered the
> incorrect behaviour required by the specification, but I don't think
> this can be taken as an argument against overflow checking...

This is a debate which has gone on before and you may be letting the
toothpaste get out of the tube. ;-) IMHO, the *real* problem was not
anything to do with language features - it was a fundamental management
problem. They decided to use a piece of very successful, reliable
software in a different application and never bothered to verify that it
would work correctly given an entirely new and different set of
requirements. The code which "broke" was only the immediate cause, but
not the fundamental reason. In my understanding, they explicitly removed
runtime checks from the code in question because of performance issues
(not at all uncommon) but then went and validated that the code would
never see anything out of range given the flight profile of the Ariane 4
rocket. Hence, the code was safe. Moving the code to Ariane 5 which had
a different flight profile changed the requirements - but the code was
never tested against those requirements. Hence the disaster.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Jean-Pierre Rosen]

Mike Silva a �crit dans le message <7k8nn5$qcb$1@its.hooked.net>...
>
>The situation is more analogous to taking a somebody who's driven for
years,
>and giving them a car which is designed such that at 60 mph it
suddenly
>shifts into reverse.  Below 60 mph everything is normal.  He's not an
idiot,
>and he's not incompetent, but no matter how hard he tries one day
he's going
>to forget and exceed 60 mph and whammo! (but hey, it was in the
manual!)
>Things designed to be used by humans should strive for "reasonable",
>"expected" behavior whenever possible, and should notify the human
when
>that's not possible.
>
Compare these quotes (from memory):
From one of the early books on C by K&R:
"C was designed with the idea that the programmer is a reasonable
person who knows what he's doing".

From the introduction of the Ada LRM:
"Ada was designed with consideration that programming is a human
activity".

I'll let the reader meditate that these considerations lead to
completely opposed solutions...
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Ada and Java. different behaviour. casting long to int problem.

[Jean-Pierre Rosen]

Hyman Rosen a �crit dans le message ...
>Looks like it's time to mention again that an unhandled exception
>raised by conversion overflow caused the Ariane 5 rocket to go off
>course, resulting in its destruction.
>
Please read the report.
The Ariane 501 failure was caused by the *removal* of a necessary
check.
Ada then diagnosed correctly the error, and did what the
specifications required it to do in this case: it made a memory dump
which was interpreted by the flight computer as positionnal data.
You can't blame the language for doing exactly what was in the
specification; the specifications were wrong.
Of course, without overflow checking, you would'nt have triggered the
incorrect behaviour required by the specification, but I don't think
this can be taken as an argument against overflow checking...
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Ada and Java. different behaviour. casting long to int problem.

[Jean-Pierre Rosen]

Mark Hood a �crit dans le message ...
>
>I agree with this line of thinking, except that I think that the Java
>primitive types ought to be left alone, and that specialized classes
written
>to more closely emulate the behavior of mathematical integers would
be the
>appropriate solution to these issues.
>
Except that you lose two important features:
- value semantics
- operators
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Ada and Java. different behaviour. casting long to int problem.

[D'Arcy Smith]

Markus Kuhn wrote:

> Ada just supports you well if you want to write very carefully
> engineered and highly maintainable code. It certainly does not
> force you to do so. No language could.

Ah - so I wouldn;t want an inexperienced programmer in any
language to write life critical applications :-)... but Ada
makes it a bit safer.

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com

Re: Ada and Java. different behaviour. casting long to int problem.

[Hyman Rosen]

"Robert I. Eachus" <eachus@mitre.org> writes:
>     It may be time again to point out that that the software behaved
> exactly as it was intended to behave.

Yes, but the rocket blew up! C programmers will make the same claim on
wraparound arithmetic - the program behaves exactly as intended, and
if you suspect and don't want wraparound, you need to explicitly
check.

All I'm saying is that exceptions are better than wraparound only in
the test/debug environment. Out in the field, especially when the
software must work the first time, exceptions are probably going to be
more harmful than wraparound, because the former causes a large part
of the code to abruptly abort, while the latter causes a local
error. In many cases, the local error just causes a glitch but the
system as a whole can continue working.

Re: Ada and Java. different behaviour. casting long to int problem.

[David Botton]

AdaMagic and OA are already doing it for most of Ada now (missing tasks and
protected types, although they can be emulated using JDK calls).

So, Ada is way ahead of the game and already runs native and on the p-code
(whoops bytecode :) machine, the JVM.

So, Ada has the LARGEST Standard Library in the world! It has the JDK and
the standard Ada packages.

Not only that, but a large part of this MASSIVE Standard Library is really a
Standard and under the ISO, i.e.. the Ada packages.

David Botton

Aidan Skinner wrote in message ...
>
>>Ada is a different language for different purposes. You don't
>>expect a compiled Ada program to run on anything but the
>>specific processor/system it was compiled for.
>
>Depends, JGnat is apparently coming along nicely... ;)

Re: Ada and Java. different behaviour. casting long to int problem.

[David Botton]

Markus Kuhn wrote in message <7kb9ep$hej$1@pegasus.csx.cam.ac.uk>...
>Mark Hood <hood@eng.sun.com> writes:
>For me, Ada95 combines the best of both the C and the Java world:
>High performance, low-level access as well as type safety, and comfort.
>It is amazing how underhyped this equally young language is
>compared to Java in the trade press. But then, who asks the trade
>press ...
>


Don't forget that it also affords you the engineering tools for programming
in the large that C and Java don't have and C++ is only attempting to deal
with now.

David Botton

Re: Ada and Java. different behaviour. casting long to int problem.

[Matthew Heaney]

On 18 Jun 1999 11:15, dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

> ...but i think that Java is easier to read in some circumstances. You don't
> end up having the code cluttered up with ".all", "'access" and "access".

It depends on your style of programming.  Access parameters were added
to the language specifically to avoid having to explicitly dereference
access objects:

  declare
    Matt : Man_Access := New_Man;
  begin
    Shave (Matt);
    ...
  end;


where

  procedure Shave (Man : access Man_Type);


One thing Java does give you is automatic garbage collection, but we can
emulate that easily enough:

  type Man_Handle is private;  

  function "+" (Handle : Man_Handle) return Man_Access;


  function New_Man return Man_Handle;

  declare
    Matt : Man_Handle := New_Man;
  begin
    Shave (+Matt);
    ...
  end;


So you see, explicit dereferencing and 'Access are often unnecessary.  The
time when need to do that sort of thing is when you're programming close
to the machine (which is entirely appropriate).

Browse the Ada95 design patterns archive for more examples of access
parameter and garbage collection idioms.

<http://www.acm.org/archives/patterns.html>


    
> I also like Java's interfaces, a feature I'm not sure how Ada can replicate.

You can do something like that using access discriminants.  See the
observer series (in the patterns archive) for lots o' examples.

Re: Ada and Java. different behaviour. casting long to int problem.

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]


David Botton <David@Botton.com> a �crit dans le message :
7kcie0$17ki$1@news.gate.net...

> BTW, does any one know of a JVM written in Java?

No. But I already know the name of the product : SnailJava :-)

Pascal.

Re: Ada and Java. different behaviour. casting long to int problem.

[Aidan Skinner]

On 17 Jun 1999 17:20:12 GMT, Samuel Mize <smize@imagin.net> wrote:

>Unfortunately, referring to Ariane on comp.lang.ada is like referring
>to "Hitler" in other news groups...

I once read a book by Heinlein where there was this character very
similar to Ariane 5...[1] ;)

- Aidan

[1] This is a joke. I have never read any Heinlein. ;)
-- 
http://www.skinner.demon.co.uk/aidan/
Horses for courses, tac-nukes to be sure.

Re: Ada and Java. different behaviour. casting long to int problem.

[Aidan Skinner]

On 17 Jun 1999 11:39:46 -0700, john@smith.nospam.com
<john@smith.nospam.com> wrote: 
 
>So, unless Ada can come up with a set of libraries that come bundled
>with your GNAT compiler and ready to use and can match the
>functionalitites of those provided by Java, I am afraid Ada will

Well, now would appear an opportune moment to plug libra (again):

a pure Ada '95 library providing generic data structures such as
binary search trees, lists, stacks, queues etc and network operations
for NNTP and SMTP. Libra is available under the modified GPL, from 
http://www.skinner.demon.co.uk/aidan/programming/libra/

libra 0.1.0 will be available by this Monday and will offer all of the
above in a stable and, hopefully, bug-free manner. 

Libra 0.1.1 will include the addition of AVL-balanced trees, B-Trees,
Heaps, FTP and HTTP protocols and implementations of all the
cryptographic alogrithims that are candidates for the AES.[1][2]

- Aidan

[1] Subject to export restrictions.
[2] Thanks to Michael Roe for this bit.
-- 
http://www.skinner.demon.co.uk/aidan/
Horses for courses, tac-nukes to be sure.

Re: Ada and Java. different behaviour. casting long to int problem.

[mike]

In article <t71zf9cwuy.fsf@calumny.jyacc.com>, Hyman says...
>
 
>
>But no one generally expects arithmetic overflow exceptions, so no one
>writes exception handlers for them. 

You do not need to put special handler for this, use a general, catch all
handler. Then if interested, check for the specific handler your care about
handling.
 
The way I look at things is that, each function/procedure/method is
responsible for catching any expception it can generate. Then it either
handle them locally, or if it can not, throw them to the caller.

At worst, a programmer can simply start their method with a try, and
end it with a catch. 

But all of this is a programming and design issue. just becuase programmers
forget to do the right thing, does not mean a language should not provide
a good feature, that if the a programmer forgot to use, can lead to different
type of failure. Notice that your solution of letting the bad data exist
without raising an excpetion, will also lead to a failure, but you claim
that your failure is less bad than the failure that can result from 
exception raising. I diagree with that also as was said before.

Now, lets examine your statment again and show how illogical it is
from a different point of view.

How is your statment different from:

'But no one generally expects boundary array overrun exceptions, so no one
writes exception handlers for them'.

Array boundary overruns are the same thing. In Java or Ada, how many
programmers put special exception handlers for those? almost no one. Yet,
the language run-time does generate an exception when this happens.

Are you then saying the language should NOT throw an exception when someone
walks over the array boundaries travelling to lala land as they wish?

>As a result, when an overflow exception happens, there is no local
>handler to process it. 

So, teach people to use exception handlers correctly! (and to do more
tesing).

Bad programmers and bad design and lack of testing is NO execuse for 
not using exception handlers!
 
Mike.

Re: Ada and Java. different behaviour. casting long to int problem.

[Dale Stanbrough]

David Botton wrote:

" AdaMagic and OA are already doing it for most of Ada now (missing tasks and
  protected types, although they can be emulated using JDK calls)"


...but i think that Java is easier to read in some circumstances. You don't
end up having the code cluttered up with ".all", "'access" and "access".

I also like Java's interfaces, a feature I'm not sure how Ada can replicate.


Dale

Re: Ada and Java. different behaviour. casting long to int problem.

[David Botton]

AdaMagic already does the interfaces (see Tucker Taft's paper on it and
examples in the Ada bindings to the JDK) and I am willing to sacrifice a
little more typing now for long term maintenance, cross platform code (YES,
JVM is just another platform to Ada), flexible package structure, type
safety, tasking and protected types (soon in JGNAT), specs and bodies,
separate compiled bodies, child packages, etc. etc. etc. (Insert here just
about every improvement Ada has over C and C++ and throw it in here). I find
that even on the JVM Ada is more readable then Java. Ada was written for the
maintainer not the programmer.

I find that my code is not overly cluttered and as Ada frameworks are built
to abstract the JDK API, I think that even those with a bias will find Ada
to be far easier reading.

There is no benefit to use Java over Ada on the JVM  for Software
Engineering. There are areas where Java will excel over Ada on the JVM, but
programming in the large and anything requiring reliable correct code isn't
one of them.

Java is C on the JVM with a little less flexibility.

BTW, does any one know of a JVM written in Java?

David Botton


Dale Stanbrough wrote in message ...
>David Botton wrote:
>
>" AdaMagic and OA are already doing it for most of Ada now (missing tasks
and
>  protected types, although they can be emulated using JDK calls)"
>
>
>...but i think that Java is easier to read in some circumstances. You don't
>end up having the code cluttered up with ".all", "'access" and "access".
>
>I also like Java's interfaces, a feature I'm not sure how Ada can
replicate.
>
>
>Dale

Re: Ada and Java. different behaviour. casting long to int problem.

[Hyman Rosen]

bob@nospam.com writes:
> This logic does not make sense at all.
> 
> When an exception happen, you catch it, and then you can simply
> ignore it if that is really what you want to do depending on the
> exception, or you print some error message and also ignore it,
> or you can throw it again.  The point is, raising an exception and 
> handling it, are 2 different issues. So your point about the program 
> abruptly aborting do not make sense.

But no one generally expects arithmetic overflow exceptions, so no one
writes exception handlers for them. In the Ariane 5 case, the very line
that caused the exception was carefully examined by the designers, who
concluded that there could be no overflow, and that therefore no check
was needed.

As a result, when an overflow exception happens, there is no local
handler to process it. The exception propogates outward, destroying
subroutines in its path, until some outermost catch-all handler
finally triggers, or the program aborts. The result, to the user of
the code, can be much worse than continuing to process with bad data.

Re: Ada and Java. different behaviour. casting long to int problem.

[Hyman Rosen]

mike@ooo.nospam.com writes:
> In article <t71zf9cwuy.fsf@calumny.jyacc.com>, Hyman says...
> >But no one generally expects arithmetic overflow exceptions, so no one
> >writes exception handlers for them. 
> You do not need to put special handler for this, use a general, catch all
> handler. Then if interested, check for the specific handler your care about
> handling.

We're going in circles here. My contention is that because no one expects
these errors, the exception handler will be too far away from the source
of the error to do any good.

> The way I look at things is that, each function/procedure/method is
> responsible for catching any expception it can generate. Then it either
> handle them locally, or if it can not, throw them to the caller.

In the Ariane 5 case, everyone was absolutely convinced that the line
in question could not generate an exception, and therefore they were
unprepared to handle it.

> At worst, a programmer can simply start their method with a try, and
> end it with a catch. 

In the Ariane 5 case, efficiency considerations dictated that unnecessary
tests could not be left in the code.

> Now, lets examine your statment again and show how illogical it is
> from a different point of view.
> 
> How is your statment different from:
> 
> 'But no one generally expects boundary array overrun exceptions, so no one
> writes exception handlers for them'.

It's not different.

> Are you then saying the language should NOT throw an exception when someone
> walks over the array boundaries travelling to lala land as they wish?

I'm saying that in the field, especially in software which must work the
first time, that such an exception will do more harm than good. It's quite
possible that code will produce the externally correct effect even after
it has stepped out of the bounds of an array. It's usually not possible
for code to produce the externally correct effect when it throws an
exception.

Such exceptions help the programmer during the test and debug phase of the
programming cycle. If the delivered code is not mission-critical, then it's
even OK to let the exceptions happen where the customers can see them, so
that they can report back unforseen problems. But when the code must do its
job correctly, always, even the first time, then overflow and bounds checking
should be turned off in the field, because that way, it's more likely that
the program will be able to complete its job.

Re: Ada and Java. different behaviour. casting long to int problem.

[Dale Stanbrough]

Hyman Rosen wrote:

" > At worst, a programmer can simply start their method with a try, and
 > end it with a catch. 
  
  In the Ariane 5 case, efficiency considerations dictated that unnecessary
  tests could not be left in the code."


I'm not sure you know the field. From what i've read here and elsewhere
extra code is not left in for performance reasons, but because they don't
want code that is not going to do anything in there. 

Having software that is not used placed in production code is what
caused the failure in the first place!

(Anyway Ariane 501 was a test flight - and they found a bug. What a good 
test it was! :-)

Dale

Re: Ada and Java. different behaviour. casting long to int problem.

[Samuel Mize]

Hyman Rosen <hymie@prolifics.com> wrote:

> But when the code must do its
> job correctly, always, even the first time, then overflow and bounds checking
> should be turned off in the field, because that way, it's more likely that
> the program will be able to complete its job.

I can't agree.  This kind of code should have exception "firewalls"
built into it, so that the overflow and bounds checking help you
isolate and handle problems like corrupted data and bad memory elements.

For some systems, wraparound or saturating semantics may provide a safe
failure mode.  For others it wouldn't wouldn't.

However, I do agree with you on this: the fact that the language will
raise an exception does NOT inherently make software more reliable.
The software must be written to take advantage of the exceptions.
Otherwise, it's a toss-up whether catastrophe is more likely from
saturation, wrap-around or exceptions -- it's application-dependent.

I think Ariane demonstrates this very well.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Ada and Java. different behaviour. casting long to int problem.

[Kio]

This is Richard Riehle appropriating time on his wife's email account.
 
>
>And that is why Ada is the correct choice for safety-critical software.
>

Of course, Ada is the best choice for that (and also the best choice as
a general purpose language as well)
 
Given that Ada is the best for safety, any idea when we keep hearing more news
about defense companies and places in NASA using C++ now and even Java
instead of Ada? I've heared 2 news about some projects in these areas
switching to C++ from Ada.

It is the most stupied thing to do, but it seems now that the mandate is
off, every idiotic manager out there is making their own descision with
no understanding of the facts, and many are not choosing Ada. This will
cost us tax payers more money in wasted and failed software projects, and
will also lead to unsafe software. And it does not seem any one is doing
anything abou it.

not only that, we are back to using 50 languages, and each department
selecting which language to use on its own. so the defense and space
industry is back to where we were in 1970.

Kio

Re: Ada and Java. different behaviour. casting long to int problem.

[Sera Hirasuna]

This is Richard Riehle appropriating time on his wife's email account.


In article <t7so7rdd1u.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>Looks like it's time to mention again that an unhandled exception
>raised by conversion overflow caused the Ariane 5 rocket to go off
>course, resulting in its destruction.

This example serves us well in this kind of discusson because
it illustrates a key difference between Ada and most other 
languages:  the language design criteria.

The design criteria for Ada are critically different from those
of the C family of languages (C, C++, Java, etc.)  One of the 
most important of those criteria is that each Ada statement
should default to "safe."  That is, "safe" is the normal mode
for an Ada program construct.   The default mode for C is "unsafe."
C++ and Java inherit many of the unsafe features of C, particularly
at the algorithmic level.

It is easy to include in a language for which the default is "safe," 
features that relax those safety constraints.  It is more
difficult to start with an unsafe language and make it more safe. 

Ada permits a designer to bypass the safety default using such features
as unchecked operations and interfaces to unsafe languages.  The 
ability to bypass the default is sometimes necessary.  Sadly, some Ada 
programmers use it too often.  As long as one is designing with standard
Ada constructs, the safety is in place and an huge number of errors
are detected by the compiler.  

The Arianne engineers, if I recall correctly, chose to use one of the
unchecked operations.  Such operations have a default of "unsafe."  In
effect, unchecked operations allow a programmer the same freedom permitted
by C, C++, or Java, but require the same responsibility -- more, because
the rest of the program is under the rules of the Ada language.

It should be clear that, once one has decided to override the default
mode of the language, that decision carries enormous burden of
care.  If I tell you that crossing the freeway on foot instead of
using the pedestrian overpass will be dangerous, and you are killed
ignoring my admonition, is the pedestrian overpass at fault?  Oh yes,
you say, "The pedestrian overpass is so inconvenient."   We hear the
same argument about Ada, it is so inconvenient.  So is death.  

And that is why Ada is the correct choice for safety-critical software.

Let me emphasize that the C family languages is not evil.  It is simply
designed with different criteria than Ada.  When, to quote a former
NASA engineer, "Failure is not an option,"  the correct choice will
be Ada.  If a software failure is tolerable from time to time, C and
C++ might be good choices.  Pick the tool that best fits the need.
But do not pick a tool because it is convenient.  Don't just pick up
any old long-handled wrench when you should be using a torque wrench.
You may spend a long time drilling bolts out of head blocks.


Richard Riehle
richard@adaworks.com

Re: Ada and Java. different behaviour. casting long to int problem.

[Vladimir Olensky]

Sera Hirasuna wrote in message <7kg9is$85g@dfw-ixnews8.ix.netcom.com>...
>This is Richard Riehle appropriating time on his wife's email account.
>
>
>In article <t7so7rdd1u.fsf@calumny.jyacc.com>,
> Hyman Rosen <hymie@prolifics.com> wrote:

>
>This example serves us well in this kind of discusson because
>it illustrates a key difference between Ada and most other
>languages:  the language design criteria.
>
>The design criteria for Ada are critically different from those
>of the C family of languages (C, C++, Java, etc.)  One of the
>most important of those criteria is that each Ada statement
>should default to "safe."  That is, "safe" is the normal mode
>for an Ada program construct.   The default mode for C is "unsafe."
>C++ and Java inherit many of the unsafe features of C, particularly
>at the algorithmic level.
>
>It is easy to include in a language for which the default is "safe,"
>features that relax those safety constraints.  It is more
>difficult to start with an unsafe language and make it more safe.
>
>Ada permits a designer to bypass the safety default using such features
>as unchecked operations and interfaces to unsafe languages.  The
>ability to bypass the default is sometimes necessary.  Sadly, some Ada
>programmers use it too often.  As long as one is designing with standard
>Ada constructs, the safety is in place and an huge number of errors
>are detected by the compiler.


I would like to add some things to the all  said above.

I think that Ada 95 design could go a little bit further and would seriously
consider  experience of M3.
M3 designers at their time had seriously considered experience of Ada 83
regarding safety and made one extremely good design decision (to my point of
view - others may have different opinions of course).
They divided all language features to safe and unsafe ones (just the same as
in Ada ).
By default system in a safe mode which is very restrictive. Program safety
is guaranteed by the M3 itself.
But any language that should be able to do something serious should allow
unsafe operations  which are usually low level operations, unchecked
conversions etc.  So M3 allows them but only in UNSAFE modules. In UNSAFE
modules it is programmer responsibility to provide system safety using
potentially unsafe operations.
As a result of such decision all (potentially) unsafe operations (if really
needed) are concentrated in  few unsafe modules and it makes it much easier
to trace all (potentially) unsafe code in the overall system design.
I think  Ada is a little bit behind M3 here.  Ada  tells that it has
potentially unsafe operations and tells that it is programmer responsibility
to provide system safety when using them (the same as M3).  But Ada allows
to use them in any piece of code, in any package. As a consequence of that
such potentially unsafe operations may be scatted all around program pieces
(packages) and this makes it difficult to trace all potentially unsafe
operations. Of course good system designer may concentrate such operations
in few packages and give them appropriate names (e.g. package
unsafe_something ). But nothing in the language itself forces him/her to do
so. Here I could recall frequent argument in Ada vs. C++ discussions. It is
frequently said that though C++ provide many more safety features that C
they are not often used just because nothing prevents C++ programmer from
use of unsafe features of C and that Ada is better that C++ in that respect
as it forces programmer to use safe features ( as there are only a few
number of unsafe ones).

Coming back to M3 decision about safe and unsafe operations it is very good
from overall system design management process.  If you are a manager  and
you have some number of employees you divide pieces of work and areas of
responsibility between your employees and as result you know who is
responsible for what. This forces employees to take more serious approach to
the work as they know that this is only his/her responsibility to provide
good result and there would be no one to blame for the bad result.
M3 provide the same kind of  management.
It divides areas of responsibility of providing safety between core language
itself (in the safe modules  and interfaces) and programmer (in unsafe
modules). It does not allow any unsafe operations in safe modules.
But when programmer need to use them then it defines interface/module as
unsafe and clearly understand that it is his/her responsibility to provide
needed level of safety here.
I think that advantages of such approach are very obvious and clear.
Probably reason why Ada 95 did not took such approach was requirement of
upward compatibility with Ada 83 or may be something else. I do not know.
May be people that took part in Ada design could clarify that issue.
Here I would like to stress once more that any Ada developer may follow the
same approach as in M3 (and good one probably would do so) but nothing in
the language forces him/her to do so.

-----------------------
Another thing that I would like to mention here is MDC thoughts about types
with saturation behavior.
It seems that  no one paid attention to that  as I have seen no comments
about that.
I would like to say that I fully support this idea.
Saturation is one of the fundamental things in physics, electronics,
mechanical engineering, control systems operations and many  other areas
(including mental activity as well :-)
If language could support such fundamental  types it could be very fruitful
in many areas and could add some more flexibility and safety that are
already major features of Ada.
Of course such types probably could be created by programmer itself but it
does not look to be very simple and straightforward  and it probably
requires some low level support to be efficiently implemented.

>And that is why Ada is the correct choice for safety-critical software.


Right now probably there are no other choices.
May some time later we will have one more  -  Ada-M :-)


Regards,

Vladimir Olensky

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Dale Stanbrough wrote:
> I'm not sure you know the field. From what i've read here and elsewhere
> extra code is not left in for performance reasons, but because they don't
> want code that is not going to do anything in there.
> 
O.K., It has been a while since I read the report, but let's see if my
memory is correct by putting out a claim and seeing who jumps down my
throat:

The exact point where the problem occurred was in a chunk of code which
had to execute at a very high duty cycle on a very slow processor.
Leaving the usual Ada overflow/exception raising checks in the compiled
code resulted in code that would consume way too much time, so the
original team decided to optimize by compiling without checks (quite
common, actually) and substituting their own static analysis instead.
They successfully demonstrated that within the Arian 4 flight profile
that the numbers would never get too big to handle, and so it was safe
to turn off the checks.

Within the Ariane 5 flight path, the numbers in question got
substantially bigger, so the static analysis was no longer valid. In the
segment of code in question, there was a conversion from a floating
point number to an integer (I think!) which generated a fixed-point
overflow interrupt. The 1750a processor did what it was supposed to do
which was jump to the ISR. The logic in the ISR subscribed to the
following theory: A fixed point overflow is never supposed to happen in
normal operation, so it must be the result of a hardware/sensor failure.
(Again, quite a common strategy) If there is a hardware failure, shut
down the computer and transfer to the other channel (The whole point of
dual redundancy). However, since the fault was not hardware but rather
within the software, both channels were going through pretty much the
same logic at the same time - thus causing a total shutdown of the
system. The result: Energetic Disassembly.

Now if someone remembers it better than I do, please chime in. The
essential point was that it was *not* a problem of failing to trap an
Ada exception, nor was it a problem of software design errors, nor was
it a problem resulting from turning off runtime checks. It was a
*management* problem for failing to test code at even the most
rudimentary level to verify that when they changed applications that it
still met the requirements. The software did *exactly* what it had been
designed to do - it was just being used improperly.

I hope this clarifies what was happening in the Ariane 5 situation. Now
on to that discussion about Hitler... ;-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Samuel Mize wrote:
> 
> However, I do agree with you on this: the fact that the language will
> raise an exception does NOT inherently make software more reliable.
> The software must be written to take advantage of the exceptions.
> Otherwise, it's a toss-up whether catastrophe is more likely from
> saturation, wrap-around or exceptions -- it's application-dependent.
> 
Absolutely! Thank you!

The software must be designed within the bounds of failure mode analysis
and the best behavior of the software is going to be entirely dependent
on the application at hand. Exception raising, etc. is going to do
*nothing good* for you unless you first look at how the system might
fail and what the consequences will be in the face of that failure. You
have to spend an enormous amount of time throwing out scenarios of
possible failure and asking what sort of accommodations you might make
to mitigate the failure.

I was once seriously asked: "Suppose that the CPU fails, what can you do
in software to detect this and accommodate it?"

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Mike Silva]

I'm curious -- have you actually written safety-critical code with this
approach?  I can't imagine getting such code approved, internally or
externally.  Just because the Ariane people got it wrong doesn't mean a
value range analysis can't be done correctly.  Assuming the offending
Horizontal Bias value was derived from some input sensor or sensors, these
certainly should have been range-checked and bounded in the code -- sensors
do fail...  Once your inputs (from any source) are properly constrained the
problem becomes much more manageable.

Mike

Hyman Rosen wrote in message ...

>I'm saying that in the field, especially in software which must work the
>first time, that such an exception will do more harm than good. It's quite
>possible that code will produce the externally correct effect even after
>it has stepped out of the bounds of an array. It's usually not possible
>for code to produce the externally correct effect when it throws an
>exception.
>
>Such exceptions help the programmer during the test and debug phase of the
>programming cycle. If the delivered code is not mission-critical, then it's
>even OK to let the exceptions happen where the customers can see them, so
>that they can report back unforseen problems. But when the code must do its
>job correctly, always, even the first time, then overflow and bounds
checking
>should be turned off in the field, because that way, it's more likely that
>the program will be able to complete its job.

Re: Ada and Java. different behaviour. casting long to int problem.

[Samuel T. Harris]

Sera Hirasuna wrote:
> 
> This is Richard Riehle appropriating time on his wife's email account.
> 
> In article <t7so7rdd1u.fsf@calumny.jyacc.com>,
>         Hyman Rosen <hymie@prolifics.com> wrote:
> 
> <snip>
> 
> The Arianne engineers, if I recall correctly, chose to use one of the
> unchecked operations.  Such operations have a default of "unsafe."  In
> effect, unchecked operations allow a programmer the same freedom permitted
> by C, C++, or Java, but require the same responsibility -- more, because
> the rest of the program is under the rules of the Ada language.
> 
> <snip>

The report did not mentioned an unchecked_conversion. It said
a conversion from integer to float. As someone mentioned waaayyy
back when this thread was discussed at the outset of the report,
it is common for a scaled conversion to occur. In other words,
a set of integers, say 0..255, represent a collection of
preassigned floating point values. Perhaps linear or even
logarithmic in scale. Converting between the integer and a
float or fixed-point number is not a unchecked_conversion.
Since the Ariane 5 had 4 times the thrust (if I remember this
factor correctly) one can easily see an overflow or some such
error being detected.

As has been said in this thread a couple of times, no feature
of the language was at fault either by it usage or by is
avoidance. The analysis, design, and implementation were all
based on the Ariane 4 flight trajectory and performance
characteristics. The practices employed are common and accepted
within the industry performed with due diligence as applied
to the Ariane 4. The problem was simply one of not reverifying
reused code in a new situation.

Ariane 5 flight numbers were not provided.
The bounds checks were not reanalyzed to confirm which were
needed and which were not. A no simulation tests were performed
using Ariane 5 numbers. Had a single simulation test been run
using Ariane 5 numbers then the exception would have immediately
clued the folks in on their problem. Simply running verification
tests on the software in the new situation would have avoided
the millions of dollars in cost as well as the loss of the payload.

All in all, it was a major management problem involving in the
reuse of code. The lesson to be learned is that reused code
must be reverified against the requirements of the new situation.
They cut out each and every verification step based on cost or
a perception of not needing each step. Each decision may seem
reasonable to most (read the report for details). The problem
was that they cut out _all_ of the steps they could have taken
to verify the software for th Ariane 5.

After reading the report, the only software bug I could discern
was the improper interpretation of diagnostic information provided
by the failed units to the central processer as _real_ attitude data.
That strikes me as a design/implementation flaw.

As each of the two units got their exceptions, each unit
assumed a hardware failure and provided diagnostic data to the
central processor. The central processor, instead of treating
the data as diagnostics, treated it as real altitude and attitude
data. Since this data was garbage according to this interpretation,
an huge course correction was ordered. The engine nozzles were
commanded to maximum flex causing the rocket to fly "sideways"
(kind of like a car skidding on a wet road). Flying sideways
is extremely stressful to the superstructure which began to
buckle. This buckling was detected by the appropriate sensors
and the rocket was commanded internally to self-destruct because
of the catastrophic nature of the situation. Everything after
the misinterpretation of the diagnostic data went according
to contigency plans build within the rocket itself.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"

Re: Ada and Java. different behaviour. casting long to int problem.

[Hyman Rosen]

Sera Hirasuna <serah@ix.netcom.com> writes:
> The Arianne engineers, if I recall correctly, chose to use one of the
> unchecked operations.  Such operations have a default of "unsafe."

Quite the contrary. The Ariane engineers examined the code in question,
concluded that it would behave correctly, and used a safe operation,
with no local handler in place for an exception at that point. That "safe"
operation detected the overflow and propogated the exception outward to a
handler which assumed that hardware failure had occurred.

Re: Ada and Java. different behaviour. casting long to int problem.

[Richard D Riehle]

In article <376E87D3.FA9FD42C@hso.link.com>,
	"Samuel T. Harris" <sam_harris@hso.link.com> wrote:

>The report did not mentioned an unchecked_conversion. It said
>a conversion from integer to float. 

 I stand corrected on this item.  I seem to recall that an early
 discussion of this event included some mention of unchecked_conversion,
 but, given the feedback I have had from readers, this was apparently
 not the case.  It is a long time since I read the literature.  This is
 one problem with being in the "springtime of my senility."

 Sorry for ranting on about it in my earlier post.

 Richard Riehle

 

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert Dewar]

In article <3766C842.E1EAB60A@pwfl.com>,
  diespammer@pwfl.com wrote:

> The people burnt to a crisp in the crash of an
> airplane aren't going to care that "The Programmer Should Have
> Read The
> Standard Better." Dead is just as dead if it was the compiler
> that was
> at fault. What the programmer *should* do is mostly
> irrelevant. What the
> programmer is *likely* to do is go with all of his years of
> grade school
> arithmetic and casually believe that X := X + 1 will yield the
> expected result.

This is unrealistic. The idea that safety critical software
depends on programmers doing the right thing on the basis of
"casual belief" is way off the mark.

In fact an unanticipated overflow causing an exception may be
as dangerous, if not MORE dangerous than an ignored overflow
(Ariane 5 was a nice demonstration of this).

In practice in safety critical software, formal verification
and certification techniques are used to ensure that NEITHER
event happens.

Don't worry, when you fly on a plane, regardless of the language
used, you are not at the mercy of programmers doing *anything*
casually. Safety critical software just does not work this way!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert I. Eachus]

"Samuel T. Harris" wrote:

> As has been said in this thread a couple of times, no feature
> of the language was at fault either by it usage or by is
> avoidance. The analysis, design, and implementation were all
> based on the Ariane 4 flight trajectory and performance
> characteristics. The practices employed are common and accepted
> within the industry performed with due diligence as applied
> to the Ariane 4. The problem was simply one of not reverifying
> reused code in a new situation.

    Amen!  Perfect software is no longer perfect if used outside its
design envelope.
 
> After reading the report, the only software bug I could discern
> was the improper interpretation of diagnostic information provided
> by the failed units to the central processer as _real_ attitude data.
> That strikes me as a design/implementation flaw.
 
    But it was a deliberate design decision made for good and sufficient
reasons.  Since both processors output was covered by telemetry, dumping
the internal state of the "failed" and ignored processor wouldn't hurt. 
The possibility of both processors getting to the same point was
discussed at length.  Because, on the Arianne 4, the only way to get
there was either dual hardware failures, or the rocket being way outside
its intended trajectory, the decision was made that capturing the data
was fine, because the vehicle was about to be destroyed anyway.  So it
was known that the data dump would cause the missle to possibly go
further off course, and it was accepted.

    And as I keep pointing out, none of this destroyed the Arainne 5. 
What did was that other reused software had the Arianne 4 center of
gravity, moments, and structural data built in.  The guidance computer
sent data indicating that the Arianne 5 was off course.  The correction
applied was too great for the Arainne 5 stack (rocket stack not call
stack ;-), and the stack came apart.  This could have happened even if
the guidance computer was operating "correctly."  For example upper
atmosphere winds could have caused the computers to apply a correction
which was too big for the Arianne 5 with the same result.

    The single and only point of failure was that not only did
management decide not to test the software or check it against Arianne 5
requirements, they even refused to let the original programming team SEE
the Arianne 5 engineering specs.
-- 

                                        Robert I. Eachus

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

Re: Ada and Java. different behaviour. casting long to int problem.

[Hyman Rosen]

Marin David Condic <condicma@bogon.pwfl.com> writes:
> Point taken. I don't think Ariane 5 was an issue of exception raising
> since they had removed the checks. My recollection was that it had to do
> with an overflow interrupt which caused the channel to shut down and
> transfer control to the other side (which was what the design called
> for.)

Nope. Here's the quote from the report
<http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html>:

	The internal SRI software exception was caused during
	execution of a data conversion from 64-bit floating point to
	16-bit signed integer value. The floating point number which
	was converted had a value greater than what could be
	represented by a 16-bit signed integer. This resulted in an
	Operand Error. The data conversion instructions (in Ada code)
	were not protected from causing an Operand Error, although
	other conversions of comparable variables in the same place in
	the code were protected.

> Still, an interrupt or an exception are similar in intention: Stop
> doing what you are doing and handle an unusual condition.

Yep.

Re: Ada and Java. different behaviour. casting long to int problem.

[Keith Thompson]

Hyman Rosen <hymie@prolifics.com> writes:
[...]
> Nope. Here's the quote from the report
> <http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html>:
> 
> 	The internal SRI software exception was caused during
> 	execution of a data conversion from 64-bit floating point to
> 	16-bit signed integer value. The floating point number which
> 	was converted had a value greater than what could be
> 	represented by a 16-bit signed integer. This resulted in an
> 	Operand Error. The data conversion instructions (in Ada code)
> 	were not protected from causing an Operand Error, although
> 	other conversions of comparable variables in the same place in
> 	the code were protected.

I've always found this wording a bit odd.  The way Operand Error is
capitalized implies that it's a technical term, but course there's no
predefined Ada exception by that name.  Presumably they're referring
to Constraint_Error (or possibly Numeric_Error if they were using an
Ada 83 compiler).  Perhaps "Operand Error" is the name of a
hardware-level error condition?

Also, what does "protected from causing an Operand Error" mean?  I
*think* it refers to surrounding the operation with a local exception
handler, but it's not at all clear from the report (at least to me).

Obviously the report wasn't written for an Ada-aware audience (not
that it necessarily should have been).

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

Re: Ada and Java. different behaviour. casting long to int problem.

[Richard D Riehle]

In article <37700CFC.94862F1C@mitre.org>,
	"Robert I. Eachus" <eachus@mitre.org> wrote:

>"Samuel T. Harris" wrote:
>
>> As has been said in this thread a couple of times, no feature
>> of the language was at fault either by it usage or by is
>> avoidance. The analysis, design, and implementation were all
>> based on the Ariane 4 flight trajectory and performance
>> characteristics. The practices employed are common and accepted
>> within the industry performed with due diligence as applied
>> to the Ariane 4. The problem was simply one of not reverifying
>> reused code in a new situation.
>
>    Amen!  Perfect software is no longer perfect if used outside its
>design envelope.

This reminds me of the pharmaceutical example.  Someone goes to a 
lot of trouble to create a medicine that cures some condition. The
doctor gives this perfectly good therapy to someone for whom it is
contraindicated.  The patient dies.  Arianne 4 software was apparently
contraindicated for Arianne 5.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Keith Thompson wrote:
> I've always found this wording a bit odd.  The way Operand Error is
> capitalized implies that it's a technical term, but course there's no
> predefined Ada exception by that name.  Presumably they're referring
> to Constraint_Error (or possibly Numeric_Error if they were using an
> Ada 83 compiler).  Perhaps "Operand Error" is the name of a
> hardware-level error condition?
> 
As I've said elsewhere, my recollection was that the system ended up
going to an interrupt handler and, as you observe, there is no such
thing in Ada (that I'm aware of) called Operand_Error. On the 1750a,
there is a fixed point overflow interrupt and several user definable
interrupts which may have somehow ended up tagged with this terminology. 

We have to remember that the guys who write these disaster analysis
reports are not usually experts in the specific domain wherein the error
occurs. They interview lots of technical experts and attempt to
understand exactly what happened, then write up a report. Chances are,
they were caught up in the terminology of whoever was doing the
explaining.

> Also, what does "protected from causing an Operand Error" mean?  I
> *think* it refers to surrounding the operation with a local exception
> handler, but it's not at all clear from the report (at least to me).
> 
Dittos. My recollection from other parts of the report was that the code
was running at a very high duty cycle which caused the developers to
remove the runtime checks for efficiency. This rather implies that,
having turned off checks, there was nothing to examine ranges, etc, and
explicitly generate an exception. (To raise the exception, there must be
some code generated of the form "if (X not in -32768..32767) then...",
shouldn't there?) Either that, or there has to be some sort of trapping
of the interrupt which is going to get generated, right? 

It is possible that they meant having a "begin exception end" block
around the computation, but you don't usually see people doing that.
There's usually an exception handler at the end which catches all the
errors. And since the handler in and of itself is not (usually) run-time
intrusive, there would be no reason to remove the handler in the
interest of efficiency.

Not having the original code in question in front of us is a decided
handicap...

> Obviously the report wasn't written for an Ada-aware audience (not
> that it necessarily should have been).
> 
It would have been nice for me at the time this was going down if it had
been a little more "Ada Aware" - Interpretation and explanation of how
this wasn't going to happen with *my* rocket would have been easier! It
would have been useful to have the source code - maybe.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Robert Dewar wrote:
> This is unrealistic. The idea that safety critical software
> depends on programmers doing the right thing on the basis of
> "casual belief" is way off the mark.
> 
Never said that. What I was aiming at was the issue of default semantics
for arithmetic operations. Most of the time when a programmer writes "X
:= X + 1" he's off thinking that he is going to get the successor to X.
It would be the unusual condition which would create an overflow (or
wraparound or saturation)

BTW: We do the intense verification specifically because fallible human
beings often casually assume that X := X + 1 is going to generate the
successor and someone had better test to find out what happens if it
doesn't.

> In fact an unanticipated overflow causing an exception may be
> as dangerous, if not MORE dangerous than an ignored overflow
> (Ariane 5 was a nice demonstration of this).
> 
Yup. That's why I have said elsewhere that I think there should be
different types with different semantics so that the appropriate
behavior can be selected for the application in question. Example:
Standard Integer semantics are fine for a bank balance program because
halting the program with an exception is less harmful than wrapping
around or saturating. Whereas, in most control applications, saturation
is infinitely superior to either an exception or a wraparound.

> In practice in safety critical software, formal verification
> and certification techniques are used to ensure that NEITHER
> event happens.
> 
> Don't worry, when you fly on a plane, regardless of the language
> used, you are not at the mercy of programmers doing *anything*
> casually. Safety critical software just does not work this way!
> 
I don't worry. I build this stuff for a living! :-) Because I do, I'm
very cognizant of the fact that human beings make mistakes on a regular
basis and that's why we go through multiple layers of very expensive
verification before a control is ever allowed to fly a jet engine that
is carrying people. Yet still, we design into it the "What if there is
an error somewhere that we didn't catch?" strategy which guarantees safe
and sane behavior "just in case".

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Vladimir Olensky]

Marin David Condic wrote in message <3770F79C.42132886@pwfl.com>...

> Whereas, in most control applications, saturation
>is infinitely superior to either an exception or a wraparound.


Here again I would like to express my full support to  the said above.

 I already mentioned  in this thread  that   "Saturation is one of the
fundamental things in physics, electronics, mechanical engineering, control
systems operations and many  other areas.

If language could support such fundamental  types it could be very fruitful
in many areas and could add some more flexibility and safety that are
already major features of Ada"

I think people that have anything to do with control systems design  would
fully support that also.
Saturation is fundamental nature phenomena. So if we had language feature
that support such behavior it would make that language more fundamental.


Regards,
Vladimir Olensky

Re: Ada and Java. different behaviour. casting long to int problem.

[Roedy Green]

On Wed, 23 Jun 1999 22:00:08 +0400, "Vladimir Olensky"
<vladimir_olensky@yahoo.com> wrote:

>Saturation is fundamental nature phenomena. So if we had language feature
>that support such behavior it would make that language more fundamental.

By "saturation" you mean the same thing as Abundance "corralling"?
When a variable value gets too big, you automatically corral it back
to the maximum declared allowable value for that variable.

--

Roedy Green���������������� roedy@mindprod.com 
Canadian Mind Products������telephone: (604) 435-3016
5317 Barker Avenue
Burnaby, BC CANADA V5H 2N6
<http://mindprod.com> for CMP utilities and the Java glossary 

-30-

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Vladimir Olensky wrote:
> I think people that have anything to do with control systems design  would
> fully support that also.
> Saturation is fundamental nature phenomena. So if we had language feature
> that support such behavior it would make that language more fundamental.
> 
I'd like to see how it might be added to the language in an efficient
way - preferably without having to get it as a customization of the
compiler. We've typically pulled stunts with assembly language, but that
isn't very portable nor does it lead to a "common" understanding of
where such types ought to live or what sort of standard behavior they
should have. It would be nice to see a compiler vendor provide it as an
extension to the language just to see how well it would be received &
used.

I've heard tell of some processor chips providing support for saturated
arithmetic mostly because they have found it useful for graphics
applications. Maybe more hardware support will lead to more compiler
support?

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Roedy Green wrote:
> 
> By "saturation" you mean the same thing as Abundance "corralling"?
> When a variable value gets too big, you automatically corral it back
> to the maximum declared allowable value for that variable.
> 
If I understand you correctly, the answer is "yes". In Ada, it would
look sort of like this:

X : Integer := Integer'Last ; --  Contains max value for type integer.

...

X := X + 1 ; --  No overflow - X contains Integer'Last


There is no "standard" way of getting this behavior in Ada so typically
you have to implement your own data type and operations. The only
problem is that you really need to have your math behave with all due
speed, so you degenerate to assembler or end up fussing around in other
ways that don't lend themselves to portability or good abstractions. I'd
prefer to get the support in hardware and have the compiler give me data
types (float, fixed and integer) that lined up with the hardware.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Aidan Skinner]

On Tue, 22 Jun 1999 18:23:56 -0400, Robert I. Eachus <eachus@mitre.org> wrote:

>    Amen!  Perfect software is no longer perfect if used outside its
>design envelope.

No, *perfect* software modifys what it does so as to work in any
design envelope... ;)

- Aidan
-- 
Gimme gimme gimme a shell after midnight.
Won't somebody help me take the users away.
http://www.skinner.demon.co.uk/aidan/

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Hyman Rosen wrote:
> 
> Nope. Here's the quote from the report
> <http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html>:
> 
>         The internal SRI software exception was caused during
>         execution of a data conversion from 64-bit floating point to
>         16-bit signed integer value. The floating point number which
>         was converted had a value greater than what could be
>         represented by a 16-bit signed integer. This resulted in an
>         Operand Error. The data conversion instructions (in Ada code)
>         were not protected from causing an Operand Error, although
>         other conversions of comparable variables in the same place in
>         the code were protected.
> 
I remembered correctly the floating to integer conversion being the
problem. However, this text of the report is confusing. Operand_Error is
not a standard Ada exception. If an exception were raised, it would have
to be done because of checks in the code which, to the best of my
recollection and as hinted in this chunk of the report, were removed. So
it is not clear to me that what happened here was the result of a
runtime check around a statement of the form: "Int := Integer (Flt) ;"
but could have possibly been the result of the Mil-Std-1750a generating
an interrupt (#4 - Fixed Point Overflow).

I'd have to go back and re-read the report to refresh my memory.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Keith Thompson]

Marin David Condic <condicma@bogon.pwfl.com> writes:
[...]
> If I understand you correctly, the answer is "yes". In Ada, it would
> look sort of like this:
> 
> X : Integer := Integer'Last ; --  Contains max value for type integer.
> 
> ...
> 
> X := X + 1 ; --  No overflow - X contains Integer'Last

Out of curiosity, would it generally be more useful for saturation to
be "sticky", like IEEE infinity?

For example, with non-sticky saturation, you might get something like
this:

   X : Integer := Integer'Last;
   ...
   X := X * 10;		-- saturation, X = Integer'Last
   X := X / 10;		-- X = Integer'Last / 10

On the other hand, an infinite value in IEEE floating point is not
just a large number; infinity / 10 = infinity.

I suspect the answer depends on the application, and on what kind of
further calculations you want to do on saturated results.  Making
saturation sticky would require reserving certain bit patterns in an
integer type, which would cause some run-time overhead on all
operations on that type.  It would also make conversions between a
saturating type and an equivalent non-saturating type a little tricky.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert A Duff]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> Keith Thompson wrote:
> > I've always found this wording a bit odd.  The way Operand Error is
> > capitalized implies that it's a technical term, but course there's no
> > predefined Ada exception by that name.  Presumably they're referring
> > to Constraint_Error (or possibly Numeric_Error if they were using an
> > Ada 83 compiler).  Perhaps "Operand Error" is the name of a
> > hardware-level error condition?
> > 
> As I've said elsewhere, my recollection was that the system ended up
> going to an interrupt handler and, as you observe, there is no such
> thing in Ada (that I'm aware of) called Operand_Error. On the 1750a,
> there is a fixed point overflow interrupt and several user definable
> interrupts which may have somehow ended up tagged with this terminology. 

It's not clear what sort of "data conversion" they're talking about in
the report.  Is it an Ada type_conversion, as in "Integer(Some_Float)"?
Or is it a subroutine that's doing something similar -- that could
explain the "Operand Error" -- maybe the subroutine raises that
exception.

> It is possible that they meant having a "begin exception end" block
> around the computation, but you don't usually see people doing that.
> There's usually an exception handler at the end which catches all the
> errors. And since the handler in and of itself is not (usually) run-time
> intrusive, there would be no reason to remove the handler in the
> interest of efficiency.

Unless they were worried about space efficiency.

It does seem strange that they would eliminate the exception handler,
but not eliminate the code that raises the exception, if they were that
worried about efficiency.  Which makes me think that it must have been a
hardware-detected exception.  But that would raise Constraint_Error, not
some user-defined thing called "Operand_Error".  Strange.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Keith Thompson wrote:
> Out of curiosity, would it generally be more useful for saturation to
> be "sticky", like IEEE infinity?
> 
I don't know about "generally" but I can speak for the areas where I'd
like to have it :-)

> For example, with non-sticky saturation, you might get something like
> this:
> 
>    X : Integer := Integer'Last;
>    ...
>    X := X * 10;         -- saturation, X = Integer'Last
>    X := X / 10;         -- X = Integer'Last / 10
> 
> On the other hand, an infinite value in IEEE floating point is not
> just a large number; infinity / 10 = infinity.
> 
By which you mean that once I've run over the edge, there is no coming
back? I think this would not be useful in a control application. Look at
it this way: You are commanding a valve to move somewhere between full
open and slammed shut. Assume that this is represented by an angle of
0..90 degrees. (The control laws will operate on a float or fixed point
number, then when they decide where to command the valve, they give me
the number and I translate it into a voltage (integer - d/a converter)
that commands the actuator.) If the control laws software gets nutso and
decides to command the valve to 105 degrees, I want the number to crop
off at 90 degrees and stay there until the software regains its senses
and perhaps starts commanding in the other direction.

Usually this sort of clear-cut case is handled by explicit range checks
within the system software, but the same sort of thing occurs for all
sorts of intermediate calculations. In general, it is believed that if
the control laws calculations saturate, we'll generally be better off
with where it commands things. Definitely, wraparound is bad because it
forces you to go from one extreme to the completely opposite extreme and
that is stressful on physical hardware.

You could imagine how this would also be practical for, say, graphics
applications where you are computing X/Y coordinates or RGB colors. If
you run off the edge of the window in your computation, then stay at the
max value until the computation comes back within view. Likewise for
colors - green all the way on + 1 shouldn't be green off. And eventually
the adjustment would come back within range.

> I suspect the answer depends on the application, and on what kind of
> further calculations you want to do on saturated results.  Making
> saturation sticky would require reserving certain bit patterns in an
> integer type, which would cause some run-time overhead on all
> operations on that type.  It would also make conversions between a
> saturating type and an equivalent non-saturating type a little tricky.
> 
As always, the answer is "It Depends" ;-) Sticking the value at +/-
infinity until (presumably?) the object is totally reassigned might be a
useful thing in some spots. Offhand, I can't think of any, but I'm sure
there are computations which are better off "latched" once they go
overboard.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[Mike Silva]

Keith Thompson wrote in message ...
>
>Out of curiosity, would it generally be more useful for saturation to
>be "sticky", like IEEE infinity?
>
>For example, with non-sticky saturation, you might get something like
>this:
>
>   X : Integer := Integer'Last;
>   ...
>   X := X * 10; -- saturation, X = Integer'Last
>   X := X / 10; -- X = Integer'Last / 10
>
>On the other hand, an infinite value in IEEE floating point is not
>just a large number; infinity / 10 = infinity.


In the situations I can imagine using a saturating variable (control loops)
this would *not* be good!  Suppose the value represents e.g. a control
surface output -- it's legitimate to have it "pegged" at full travel for a
while in response to a very large error (in the control loop sense) signal,
but when the error comes down and even reverses sign, you sure don't want
the control surface to stay pegged!  PID controllers can have a similar
situation called integral windup, where the internal integeral keeps
building up while the control output is pegged, and then when the error
begins to reduce and finally reverses sign that large built-up integral has
to be "emptied" by the opposite error before the control output responds
correctly -- in the meantime the output is pegged in the wrong direction.
Modern PID controllers specifically avoid this behavior, similar to the way
a non-sticky saturated variable would avoid it.

Mike

Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic]

Robert A Duff wrote:
> It's not clear what sort of "data conversion" they're talking about in
> the report.  Is it an Ada type_conversion, as in "Integer(Some_Float)"?
> Or is it a subroutine that's doing something similar -- that could
> explain the "Operand Error" -- maybe the subroutine raises that
> exception.

In the 1750a, there is a FIX opcode which converts the integer portion
of the derived operand to a 16 bit integer (EFIX for extended precision
to 32 bit integer). If the conversion results in a number that is too
large, the condition status register is set and a Fixed Point Overflow
interrupt is triggered. I looked for references to "Operand Error" but
my Fairchild book doesn't seem to have any. My best guess is this is
what triggered the problem.

> 
> > It is possible that they meant having a "begin exception end" block
> > around the computation, but you don't usually see people doing that.
> > There's usually an exception handler at the end which catches all the
> > errors. And since the handler in and of itself is not (usually) run-time
> > intrusive, there would be no reason to remove the handler in the
> > interest of efficiency.
> 
> Unless they were worried about space efficiency.
> 
In a space based Mil-Std-1750a microprocessor, you almost invariably run
out of time *way* before you run out of space. :-) 

> It does seem strange that they would eliminate the exception handler,
> but not eliminate the code that raises the exception, if they were that
> worried about efficiency.  Which makes me think that it must have been a
> hardware-detected exception.  But that would raise Constraint_Error, not
> some user-defined thing called "Operand_Error".  Strange.

That's why I was convinced they were dealing with something that
triggered an interrupt and that the interrupt handler was not generating
an Ada exception, but rather going through some failure accommodation
logic.

If this conversation keeps up, I'm going to have to go re-read the
report. ;-)


MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Ada and Java. different behaviour. casting long to int problem.

[John Merryweather Cooper]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]



tmoran@bix.com wrote:

> >to use -gnatwu for nearly all compilations -- and if you don't
> >know what -gnatwu does, go look it up :-)
> Where?
> It's in neither gnat_ug.txt nor gnat_rm.txt, dated 1/7/99.

  I checked my GNAT 3.10p manual and -gnatwu is DNE.  I've got -gnatws
-gnatwl and -gnatwe, but no -gnatwu.  Is this a GNAT 3.11 feature so far
not ported to OS/2?

jmc

[-- Attachment #2: Card for John Merryweather Cooper --]
[-- Type: text/x-vcard, Size: 362 bytes --]

begin:          vcard
fn:             John Merryweather Cooper
n:              Cooper;John Merryweather
adr:            1215 Colonial Drive;;;College Place;Washington;99324;USA
email;internet: jmcoopr@webmail.bmi.net
tel;fax:        1-509-522-1047
tel;home:       1-509-522-1047
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

Re: Ada and Java. different behaviour. casting long to int problem.

[Chad R. Meiners]

John Merryweather Cooper <jmcoopr@webmail.bmi.net> wrote in message
news:377A812B.9214EE74@webmail.bmi.net...
>
>
> tmoran@bix.com wrote:
>
> > >to use -gnatwu for nearly all compilations -- and if you don't
> > >know what -gnatwu does, go look it up :-)
> > Where?
> > It's in neither gnat_ug.txt nor gnat_rm.txt, dated 1/7/99.
>
>   I checked my GNAT 3.10p manual and -gnatwu is DNE.  I've got -gnatws
> -gnatwl and -gnatwe, but no -gnatwu.  Is this a GNAT 3.11 feature so far
> not ported to OS/2?
>
> jmc
>

-gnatwu is included in the -gnatwe description
--from the gnat_um
gnatWe
Wide character encoding method (e=n/h/u/s/e/8).
-- end of quoted text.
the 'e' is a parameter and 'u' is value for that parameter.

hope this helps.

-Chad R. Meiners

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert Dewar]

In article <930888777.471.67@news.remarQ.com>,
  "Chad R. Meiners" <crmeiners@hotmail.com> wrote:
> -gnatwu is included in the -gnatwe description
> --from the gnat_um
> gnatWe
> Wide character encoding method (e=n/h/u/s/e/8).
> -- end of quoted text.
> the 'e' is a parameter and 'u' is value for that parameter.
>
> hope this helps.


This actually might qualify as one of the all time *unhelpful*
comments since it is 100% irrelevant :-)

1. This describes -gnatWu, not -gnatwu

2. -gnatwu is indeed not available in version 3.10

Regarding the OS/2 port, which has been in a rather moribund
state for a while with respect to releases, there is good news
on the horizon, we just ordered a new fast machine which will
be running OS/2 all the time, and one of whose important
functions is to do regular OS/2 builds. This means that there
will indeed be a 3.12p OS/2 release, probably coming out about
the same time as other 3.12p releases, currently we hope this
will be before the end of July.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada and Java. different behaviour. casting long to int problem.

[John Merryweather Cooper]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]



Robert Dewar wrote:

> In article <930888777.471.67@news.remarQ.com>,

< SNIP! >

> This actually might qualify as one of the all time *unhelpful*
> comments since it is 100% irrelevant :-)
>
> 1. This describes -gnatWu, not -gnatwu
>
> 2. -gnatwu is indeed not available in version 3.10
>
> Regarding the OS/2 port, which has been in a rather moribund
> state for a while with respect to releases, there is good news
> on the horizon, we just ordered a new fast machine which will
> be running OS/2 all the time, and one of whose important
> functions is to do regular OS/2 builds. This means that there
> will indeed be a 3.12p OS/2 release, probably coming out about
> the same time as other 3.12p releases, currently we hope this
> will be before the end of July.
>
> Robert Dewar
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

  Yes, this is very good news.  If you could, please let me know when it
comes out.

jmc

[-- Attachment #2: Card for John Merryweather Cooper --]
[-- Type: text/x-vcard, Size: 362 bytes --]

begin:          vcard
fn:             John Merryweather Cooper
n:              Cooper;John Merryweather
adr:            1215 Colonial Drive;;;College Place;Washington;99324;USA
email;internet: jmcoopr@webmail.bmi.net
tel;fax:        1-509-522-1047
tel;home:       1-509-522-1047
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

Re: Ada and Java. different behaviour. casting long to int problem.

[Robert Dewar]

In article <377D80A2.24F9706B@webmail.bmi.net>,
  John Merryweather Cooper <jmcoopr@webmail.bmi.net> wrote:
>  Yes, this is very good news.  If you could, please let me
> know when it comes out.

We announce the availability of new versions of GNAT (both
GNAT Professional, and corresponding public versions) as they
become available on CLA and elsewhere.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada and Java. different behaviour. casting long to int problem.

[Geoff Bull]

bill@world.nospam.com wrote:
> 

> Why is it that java throws a run-time exception when one attempts to
> write passed array boundary, but closes it eyes when an overflow occurs?

Because Java's checks are designed to ensure the security of the JVM,
not detect programming errors.
That they catch any programming errors is merely a pleasant side effect.

(This is, of course, my personal opinion).