* Ada and Java. different behaviour. casting long to int problem. @ 1999-06-12 0:00 nabbasi 1999-06-12 0:00 ` nabbasi 1999-06-12 0:00 ` Tucker Taft 0 siblings, 2 replies; 120+ messages in thread From: nabbasi @ 1999-06-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 Ada and Java. different behaviour. casting long to int problem nabbasi @ 1999-06-12 0:00 ` nabbasi 1999-06-12 0:00 ` jerry 1999-06-12 0:00 ` Tucker Taft 1 sibling, 1 reply; 120+ messages in thread From: nabbasi @ 1999-06-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` nabbasi @ 1999-06-12 0:00 ` jerry 1999-06-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 120+ messages in thread From: jerry @ 1999-06-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` jerry @ 1999-06-12 0:00 ` Robert Dewar 1999-06-14 0:00 ` Marin David Condic 0 siblings, 1 reply; 120+ messages in thread From: Robert Dewar @ 1999-06-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` Robert Dewar @ 1999-06-14 0:00 ` Marin David Condic 0 siblings, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-14 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 Ada and Java. different behaviour. casting long to int problem nabbasi 1999-06-12 0:00 ` nabbasi @ 1999-06-12 0:00 ` Tucker Taft 1999-06-12 0:00 ` PPAATT ` (2 more replies) 1 sibling, 3 replies; 120+ messages in thread From: Tucker Taft @ 1999-06-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` Tucker Taft @ 1999-06-12 0:00 ` PPAATT 1999-06-12 0:00 ` Keith Thompson 1999-06-13 0:00 ` Robert Dewar 2 siblings, 0 replies; 120+ messages in thread From: PPAATT @ 1999-06-12 0:00 UTC (permalink / raw) > 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` Tucker Taft 1999-06-12 0:00 ` PPAATT @ 1999-06-12 0:00 ` Keith Thompson 1999-06-12 0:00 ` kirck 1999-06-13 0:00 ` Robert Dewar 2 siblings, 1 reply; 120+ messages in thread From: Keith Thompson @ 1999-06-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` Keith Thompson @ 1999-06-12 0:00 ` kirck 1999-06-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 120+ messages in thread From: kirck @ 1999-06-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` kirck @ 1999-06-13 0:00 ` Robert Dewar 1999-06-12 0:00 ` Fred 0 siblings, 1 reply; 120+ messages in thread From: Robert Dewar @ 1999-06-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-13 0:00 ` Robert Dewar @ 1999-06-12 0:00 ` Fred 1999-06-14 0:00 ` Mark Hood 0 siblings, 1 reply; 120+ messages in thread From: Fred @ 1999-06-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` Fred @ 1999-06-14 0:00 ` Mark Hood 1999-06-15 0:00 ` mike 1999-06-17 0:00 ` Markus Kuhn 0 siblings, 2 replies; 120+ messages in thread From: Mark Hood @ 1999-06-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-14 0:00 ` Mark Hood @ 1999-06-15 0:00 ` mike 1999-06-15 0:00 ` D'Arcy Smith ` (2 more replies) 1999-06-17 0:00 ` Markus Kuhn 1 sibling, 3 replies; 120+ messages in thread From: mike @ 1999-06-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` mike @ 1999-06-15 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` George W. Bayles 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` Samuel Mize 2 siblings, 1 reply; 120+ messages in thread From: D'Arcy Smith @ 1999-06-15 0:00 UTC (permalink / raw) To: mike 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` D'Arcy Smith @ 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith ` (2 more replies) 0 siblings, 3 replies; 120+ messages in thread From: George W. Bayles @ 1999-06-16 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles @ 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Matthew Heaney 1999-06-17 0:00 ` Aidan Skinner 2 siblings, 0 replies; 120+ messages in thread From: D'Arcy Smith @ 1999-06-16 0:00 UTC (permalink / raw) To: George W. Bayles "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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith @ 1999-06-17 0:00 ` Matthew Heaney 1999-06-17 0:00 ` Aidan Skinner 2 siblings, 0 replies; 120+ messages in thread From: Matthew Heaney @ 1999-06-17 0:00 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Matthew Heaney @ 1999-06-17 0:00 ` Aidan Skinner 2 siblings, 0 replies; 120+ messages in thread From: Aidan Skinner @ 1999-06-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` mike 1999-06-15 0:00 ` D'Arcy Smith @ 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` Mike Silva ` (2 more replies) 1999-06-15 0:00 ` Samuel Mize 2 siblings, 3 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-15 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Marin David Condic @ 1999-06-15 0:00 ` Mike Silva 1999-06-15 0:00 ` rich 1999-06-16 0:00 ` Mark Hood 1999-06-17 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 120+ messages in thread From: Mike Silva @ 1999-06-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Mike Silva @ 1999-06-15 0:00 ` rich 1999-06-15 0:00 ` Samuel Mize ` (2 more replies) 0 siblings, 3 replies; 120+ messages in thread From: rich @ 1999-06-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` rich @ 1999-06-15 0:00 ` Samuel Mize 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` tmoran 2 siblings, 0 replies; 120+ messages in thread From: Samuel Mize @ 1999-06-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` rich 1999-06-15 0:00 ` Samuel Mize @ 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` D'Arcy Smith 1999-06-22 0:00 ` Robert Dewar 1999-06-15 0:00 ` tmoran 2 siblings, 2 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-15 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Marin David Condic @ 1999-06-15 0:00 ` D'Arcy Smith 1999-06-15 0:00 ` Keith Thompson ` (3 more replies) 1999-06-22 0:00 ` Robert Dewar 1 sibling, 4 replies; 120+ messages in thread From: D'Arcy Smith @ 1999-06-15 0:00 UTC (permalink / raw) To: diespammer 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` D'Arcy Smith @ 1999-06-15 0:00 ` Keith Thompson 1999-06-16 0:00 ` bill 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` George W. Bayles ` (2 subsequent siblings) 3 siblings, 2 replies; 120+ messages in thread From: Keith Thompson @ 1999-06-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Keith Thompson @ 1999-06-16 0:00 ` bill 1999-06-16 0:00 ` George W. Bayles 1999-07-20 0:00 ` Geoff Bull 1999-06-16 0:00 ` D'Arcy Smith 1 sibling, 2 replies; 120+ messages in thread From: bill @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` bill @ 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` Fraser Wilson ` (2 more replies) 1999-07-20 0:00 ` Geoff Bull 1 sibling, 3 replies; 120+ messages in thread From: George W. Bayles @ 1999-06-16 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles @ 1999-06-16 0:00 ` Fraser Wilson 1999-06-17 0:00 ` Chris Dollin 1999-06-17 0:00 ` Aidan Skinner 2 siblings, 0 replies; 120+ messages in thread From: Fraser Wilson @ 1999-06-16 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` Fraser Wilson @ 1999-06-17 0:00 ` Chris Dollin 1999-06-17 0:00 ` Aidan Skinner 2 siblings, 0 replies; 120+ messages in thread From: Chris Dollin @ 1999-06-17 0:00 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` Fraser Wilson 1999-06-17 0:00 ` Chris Dollin @ 1999-06-17 0:00 ` Aidan Skinner 1999-06-17 0:00 ` David Botton 2 siblings, 1 reply; 120+ messages in thread From: Aidan Skinner @ 1999-06-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Aidan Skinner @ 1999-06-17 0:00 ` David Botton 1999-06-18 0:00 ` Dale Stanbrough 0 siblings, 1 reply; 120+ messages in thread From: David Botton @ 1999-06-17 0:00 UTC (permalink / raw) 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... ;) ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` David Botton @ 1999-06-18 0:00 ` Dale Stanbrough 1999-06-18 0:00 ` Matthew Heaney 1999-06-18 0:00 ` David Botton 0 siblings, 2 replies; 120+ messages in thread From: Dale Stanbrough @ 1999-06-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` Dale Stanbrough @ 1999-06-18 0:00 ` Matthew Heaney 1999-06-18 0:00 ` David Botton 1 sibling, 0 replies; 120+ messages in thread From: Matthew Heaney @ 1999-06-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` Dale Stanbrough 1999-06-18 0:00 ` Matthew Heaney @ 1999-06-18 0:00 ` David Botton 1999-06-18 0:00 ` Pascal Obry 1 sibling, 1 reply; 120+ messages in thread From: David Botton @ 1999-06-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` David Botton @ 1999-06-18 0:00 ` Pascal Obry 0 siblings, 0 replies; 120+ messages in thread From: Pascal Obry @ 1999-06-18 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` bill 1999-06-16 0:00 ` George W. Bayles @ 1999-07-20 0:00 ` Geoff Bull 1 sibling, 0 replies; 120+ messages in thread From: Geoff Bull @ 1999-07-20 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Keith Thompson 1999-06-16 0:00 ` bill @ 1999-06-16 0:00 ` D'Arcy Smith 1 sibling, 0 replies; 120+ messages in thread From: D'Arcy Smith @ 1999-06-16 0:00 UTC (permalink / raw) To: Keith Thompson 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` D'Arcy Smith 1999-06-15 0:00 ` Keith Thompson @ 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith ` (3 more replies) 1999-06-16 0:00 ` Marin David Condic 1999-06-16 0:00 ` Mike Silva 3 siblings, 4 replies; 120+ messages in thread From: George W. Bayles @ 1999-06-16 0:00 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles @ 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` Tucker Taft ` (2 subsequent siblings) 3 siblings, 0 replies; 120+ messages in thread From: D'Arcy Smith @ 1999-06-16 0:00 UTC (permalink / raw) To: George W. Bayles "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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith @ 1999-06-16 0:00 ` Tucker Taft 1999-06-17 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Larry Kilgallen 3 siblings, 1 reply; 120+ messages in thread From: Tucker Taft @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Tucker Taft @ 1999-06-17 0:00 ` George W. Bayles 1999-06-17 0:00 ` Tucker Taft 0 siblings, 1 reply; 120+ messages in thread From: George W. Bayles @ 1999-06-17 0:00 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` George W. Bayles @ 1999-06-17 0:00 ` Tucker Taft 1999-06-17 0:00 ` bob 0 siblings, 1 reply; 120+ messages in thread From: Tucker Taft @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Tucker Taft @ 1999-06-17 0:00 ` bob 0 siblings, 0 replies; 120+ messages in thread From: bob @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` Tucker Taft @ 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Larry Kilgallen 3 siblings, 0 replies; 120+ messages in thread From: D'Arcy Smith @ 1999-06-16 0:00 UTC (permalink / raw) To: George W. Bayles "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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` George W. Bayles ` (2 preceding siblings ...) 1999-06-16 0:00 ` D'Arcy Smith @ 1999-06-17 0:00 ` Larry Kilgallen 3 siblings, 0 replies; 120+ messages in thread From: Larry Kilgallen @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` D'Arcy Smith 1999-06-15 0:00 ` Keith Thompson 1999-06-16 0:00 ` George W. Bayles @ 1999-06-16 0:00 ` Marin David Condic 1999-06-16 0:00 ` Mike Silva 3 siblings, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-16 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` D'Arcy Smith ` (2 preceding siblings ...) 1999-06-16 0:00 ` Marin David Condic @ 1999-06-16 0:00 ` Mike Silva 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Jean-Pierre Rosen 3 siblings, 2 replies; 120+ messages in thread From: Mike Silva @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Mike Silva @ 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` kirk 1999-06-17 0:00 ` Jean-Pierre Rosen 1 sibling, 1 reply; 120+ messages in thread From: D'Arcy Smith @ 1999-06-16 0:00 UTC (permalink / raw) To: Mike Silva 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` D'Arcy Smith @ 1999-06-16 0:00 ` kirk 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` Hyman Rosen 0 siblings, 2 replies; 120+ messages in thread From: kirk @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` kirk @ 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Markus Kuhn 1999-06-16 0:00 ` Hyman Rosen 1 sibling, 1 reply; 120+ messages in thread From: D'Arcy Smith @ 1999-06-16 0:00 UTC (permalink / raw) To: kirk 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` D'Arcy Smith @ 1999-06-17 0:00 ` Markus Kuhn 1999-06-17 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` john 0 siblings, 2 replies; 120+ messages in thread From: Markus Kuhn @ 1999-06-17 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Markus Kuhn @ 1999-06-17 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` john 1 sibling, 0 replies; 120+ messages in thread From: D'Arcy Smith @ 1999-06-17 0:00 UTC (permalink / raw) To: Markus Kuhn 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Markus Kuhn 1999-06-17 0:00 ` D'Arcy Smith @ 1999-06-17 0:00 ` john 1999-06-17 0:00 ` Ed Falis 1999-06-18 0:00 ` Aidan Skinner 1 sibling, 2 replies; 120+ messages in thread From: john @ 1999-06-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` john @ 1999-06-17 0:00 ` Ed Falis 1999-06-18 0:00 ` Aidan Skinner 1 sibling, 0 replies; 120+ messages in thread From: Ed Falis @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` john 1999-06-17 0:00 ` Ed Falis @ 1999-06-18 0:00 ` Aidan Skinner 1 sibling, 0 replies; 120+ messages in thread From: Aidan Skinner @ 1999-06-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` kirk 1999-06-16 0:00 ` D'Arcy Smith @ 1999-06-16 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Robert I. Eachus ` (3 more replies) 1 sibling, 4 replies; 120+ messages in thread From: Hyman Rosen @ 1999-06-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Hyman Rosen @ 1999-06-17 0:00 ` Robert I. Eachus 1999-06-17 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Markus Kuhn ` (2 subsequent siblings) 3 siblings, 1 reply; 120+ messages in thread From: Robert I. Eachus @ 1999-06-17 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Robert I. Eachus @ 1999-06-17 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Marin David Condic 1999-06-17 0:00 ` bob 0 siblings, 2 replies; 120+ messages in thread From: Hyman Rosen @ 1999-06-17 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Hyman Rosen @ 1999-06-17 0:00 ` Marin David Condic 1999-06-17 0:00 ` bob 1 sibling, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-17 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Marin David Condic @ 1999-06-17 0:00 ` bob 1999-06-18 0:00 ` Hyman Rosen 1 sibling, 1 reply; 120+ messages in thread From: bob @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` bob @ 1999-06-18 0:00 ` Hyman Rosen 1999-06-18 0:00 ` mike 0 siblings, 1 reply; 120+ messages in thread From: Hyman Rosen @ 1999-06-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` Hyman Rosen @ 1999-06-18 0:00 ` mike 1999-06-18 0:00 ` Hyman Rosen 0 siblings, 1 reply; 120+ messages in thread From: mike @ 1999-06-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` mike @ 1999-06-18 0:00 ` Hyman Rosen 1999-06-19 0:00 ` Samuel Mize ` (2 more replies) 0 siblings, 3 replies; 120+ messages in thread From: Hyman Rosen @ 1999-06-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` Hyman Rosen @ 1999-06-19 0:00 ` Samuel Mize 1999-06-21 0:00 ` Marin David Condic 1999-06-19 0:00 ` Dale Stanbrough 1999-06-21 0:00 ` Mike Silva 2 siblings, 1 reply; 120+ messages in thread From: Samuel Mize @ 1999-06-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-19 0:00 ` Samuel Mize @ 1999-06-21 0:00 ` Marin David Condic 0 siblings, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-21 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` Hyman Rosen 1999-06-19 0:00 ` Samuel Mize @ 1999-06-19 0:00 ` Dale Stanbrough 1999-06-21 0:00 ` Marin David Condic 1999-06-21 0:00 ` Mike Silva 2 siblings, 1 reply; 120+ messages in thread From: Dale Stanbrough @ 1999-06-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-19 0:00 ` Dale Stanbrough @ 1999-06-21 0:00 ` Marin David Condic 0 siblings, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-21 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-18 0:00 ` Hyman Rosen 1999-06-19 0:00 ` Samuel Mize 1999-06-19 0:00 ` Dale Stanbrough @ 1999-06-21 0:00 ` Mike Silva 2 siblings, 0 replies; 120+ messages in thread From: Mike Silva @ 1999-06-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Robert I. Eachus @ 1999-06-17 0:00 ` Markus Kuhn 1999-06-17 0:00 ` Jean-Pierre Rosen 1999-06-20 0:00 ` Sera Hirasuna 3 siblings, 0 replies; 120+ messages in thread From: Markus Kuhn @ 1999-06-17 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Robert I. Eachus 1999-06-17 0:00 ` Markus Kuhn @ 1999-06-17 0:00 ` Jean-Pierre Rosen 1999-06-17 0:00 ` Marin David Condic 1999-06-20 0:00 ` Sera Hirasuna 3 siblings, 1 reply; 120+ messages in thread From: Jean-Pierre Rosen @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Jean-Pierre Rosen @ 1999-06-17 0:00 ` Marin David Condic 1999-06-17 0:00 ` Samuel Mize 0 siblings, 1 reply; 120+ messages in thread From: Marin David Condic @ 1999-06-17 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Marin David Condic @ 1999-06-17 0:00 ` Samuel Mize 1999-06-17 0:00 ` Marin David Condic 1999-06-18 0:00 ` Aidan Skinner 0 siblings, 2 replies; 120+ messages in thread From: Samuel Mize @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Samuel Mize @ 1999-06-17 0:00 ` Marin David Condic 1999-06-22 0:00 ` Hyman Rosen 1999-06-18 0:00 ` Aidan Skinner 1 sibling, 1 reply; 120+ messages in thread From: Marin David Condic @ 1999-06-17 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Marin David Condic @ 1999-06-22 0:00 ` Hyman Rosen 1999-06-22 0:00 ` Keith Thompson 1999-06-23 0:00 ` Marin David Condic 0 siblings, 2 replies; 120+ messages in thread From: Hyman Rosen @ 1999-06-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-22 0:00 ` Hyman Rosen @ 1999-06-22 0:00 ` Keith Thompson 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Marin David Condic 1 sibling, 1 reply; 120+ messages in thread From: Keith Thompson @ 1999-06-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-22 0:00 ` Keith Thompson @ 1999-06-23 0:00 ` Marin David Condic 1999-06-24 0:00 ` Robert A Duff 0 siblings, 1 reply; 120+ messages in thread From: Marin David Condic @ 1999-06-23 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Marin David Condic @ 1999-06-24 0:00 ` Robert A Duff 1999-06-24 0:00 ` Marin David Condic 0 siblings, 1 reply; 120+ messages in thread From: Robert A Duff @ 1999-06-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-24 0:00 ` Robert A Duff @ 1999-06-24 0:00 ` Marin David Condic 0 siblings, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-24 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-22 0:00 ` Hyman Rosen 1999-06-22 0:00 ` Keith Thompson @ 1999-06-23 0:00 ` Marin David Condic 1 sibling, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-23 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Samuel Mize 1999-06-17 0:00 ` Marin David Condic @ 1999-06-18 0:00 ` Aidan Skinner 1 sibling, 0 replies; 120+ messages in thread From: Aidan Skinner @ 1999-06-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Hyman Rosen ` (2 preceding siblings ...) 1999-06-17 0:00 ` Jean-Pierre Rosen @ 1999-06-20 0:00 ` Sera Hirasuna 1999-06-19 0:00 ` Kio ` (3 more replies) 3 siblings, 4 replies; 120+ messages in thread From: Sera Hirasuna @ 1999-06-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-20 0:00 ` Sera Hirasuna @ 1999-06-19 0:00 ` Kio 1999-06-20 0:00 ` Vladimir Olensky ` (2 subsequent siblings) 3 siblings, 0 replies; 120+ messages in thread From: Kio @ 1999-06-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-20 0:00 ` Sera Hirasuna 1999-06-19 0:00 ` Kio @ 1999-06-20 0:00 ` Vladimir Olensky 1999-06-21 0:00 ` Samuel T. Harris 1999-06-21 0:00 ` Hyman Rosen 3 siblings, 0 replies; 120+ messages in thread From: Vladimir Olensky @ 1999-06-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-20 0:00 ` Sera Hirasuna 1999-06-19 0:00 ` Kio 1999-06-20 0:00 ` Vladimir Olensky @ 1999-06-21 0:00 ` Samuel T. Harris 1999-06-22 0:00 ` Robert I. Eachus 1999-06-22 0:00 ` Richard D Riehle 1999-06-21 0:00 ` Hyman Rosen 3 siblings, 2 replies; 120+ messages in thread From: Samuel T. Harris @ 1999-06-21 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-21 0:00 ` Samuel T. Harris @ 1999-06-22 0:00 ` Robert I. Eachus 1999-06-23 0:00 ` Aidan Skinner 1999-06-23 0:00 ` Richard D Riehle 1999-06-22 0:00 ` Richard D Riehle 1 sibling, 2 replies; 120+ messages in thread From: Robert I. Eachus @ 1999-06-22 0:00 UTC (permalink / raw) "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... ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-22 0:00 ` Robert I. Eachus @ 1999-06-23 0:00 ` Aidan Skinner 1999-06-23 0:00 ` Richard D Riehle 1 sibling, 0 replies; 120+ messages in thread From: Aidan Skinner @ 1999-06-23 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-22 0:00 ` Robert I. Eachus 1999-06-23 0:00 ` Aidan Skinner @ 1999-06-23 0:00 ` Richard D Riehle 1 sibling, 0 replies; 120+ messages in thread From: Richard D Riehle @ 1999-06-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-21 0:00 ` Samuel T. Harris 1999-06-22 0:00 ` Robert I. Eachus @ 1999-06-22 0:00 ` Richard D Riehle 1 sibling, 0 replies; 120+ messages in thread From: Richard D Riehle @ 1999-06-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-20 0:00 ` Sera Hirasuna ` (2 preceding siblings ...) 1999-06-21 0:00 ` Samuel T. Harris @ 1999-06-21 0:00 ` Hyman Rosen 3 siblings, 0 replies; 120+ messages in thread From: Hyman Rosen @ 1999-06-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Mike Silva 1999-06-16 0:00 ` D'Arcy Smith @ 1999-06-17 0:00 ` Jean-Pierre Rosen 1 sibling, 0 replies; 120+ messages in thread From: Jean-Pierre Rosen @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` D'Arcy Smith @ 1999-06-22 0:00 ` Robert Dewar 1999-06-23 0:00 ` Marin David Condic 1 sibling, 1 reply; 120+ messages in thread From: Robert Dewar @ 1999-06-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-22 0:00 ` Robert Dewar @ 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 120+ messages in thread From: Marin David Condic @ 1999-06-23 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Marin David Condic @ 1999-06-23 0:00 ` Vladimir Olensky 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Roedy Green 0 siblings, 2 replies; 120+ messages in thread From: Vladimir Olensky @ 1999-06-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Vladimir Olensky @ 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Roedy Green 1 sibling, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-23 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Vladimir Olensky 1999-06-23 0:00 ` Marin David Condic @ 1999-06-23 0:00 ` Roedy Green 1999-06-23 0:00 ` Marin David Condic 1 sibling, 1 reply; 120+ messages in thread From: Roedy Green @ 1999-06-23 0:00 UTC (permalink / raw) 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- ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Roedy Green @ 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Keith Thompson 0 siblings, 1 reply; 120+ messages in thread From: Marin David Condic @ 1999-06-23 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Marin David Condic @ 1999-06-23 0:00 ` Keith Thompson 1999-06-24 0:00 ` Marin David Condic 1999-06-24 0:00 ` Mike Silva 0 siblings, 2 replies; 120+ messages in thread From: Keith Thompson @ 1999-06-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Keith Thompson @ 1999-06-24 0:00 ` Marin David Condic 1999-06-24 0:00 ` Mike Silva 1 sibling, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-24 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-23 0:00 ` Keith Thompson 1999-06-24 0:00 ` Marin David Condic @ 1999-06-24 0:00 ` Mike Silva 1 sibling, 0 replies; 120+ messages in thread From: Mike Silva @ 1999-06-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` rich 1999-06-15 0:00 ` Samuel Mize 1999-06-15 0:00 ` Marin David Condic @ 1999-06-15 0:00 ` tmoran 1999-06-15 0:00 ` David Botton ` (2 more replies) 2 siblings, 3 replies; 120+ messages in thread From: tmoran @ 1999-06-15 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` tmoran @ 1999-06-15 0:00 ` David Botton 1999-06-16 0:00 ` Samuel Mize 1999-06-16 0:00 ` Richard D Riehle 2 siblings, 0 replies; 120+ messages in thread From: David Botton @ 1999-06-15 0:00 UTC (permalink / raw) Unless the language is marketed right :-) David Botton tmoran@bix.com wrote in message ... > A language that needs perfect programmers will have few programmers. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` tmoran 1999-06-15 0:00 ` David Botton @ 1999-06-16 0:00 ` Samuel Mize 1999-06-16 0:00 ` Richard D Riehle 2 siblings, 0 replies; 120+ messages in thread From: Samuel Mize @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` tmoran 1999-06-15 0:00 ` David Botton 1999-06-16 0:00 ` Samuel Mize @ 1999-06-16 0:00 ` Richard D Riehle 2 siblings, 0 replies; 120+ messages in thread From: Richard D Riehle @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` Mike Silva @ 1999-06-16 0:00 ` Mark Hood 1999-06-17 0:00 ` Jean-Pierre Rosen 1999-06-17 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 120+ messages in thread From: Mark Hood @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Mark Hood @ 1999-06-17 0:00 ` Jean-Pierre Rosen 0 siblings, 0 replies; 120+ messages in thread From: Jean-Pierre Rosen @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` Mike Silva 1999-06-16 0:00 ` Mark Hood @ 1999-06-17 0:00 ` Robert I. Eachus 1999-06-17 0:00 ` Marin David Condic 2 siblings, 1 reply; 120+ messages in thread From: Robert I. Eachus @ 1999-06-17 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Robert I. Eachus @ 1999-06-17 0:00 ` Marin David Condic 0 siblings, 0 replies; 120+ messages in thread From: Marin David Condic @ 1999-06-17 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` mike 1999-06-15 0:00 ` D'Arcy Smith 1999-06-15 0:00 ` Marin David Condic @ 1999-06-15 0:00 ` Samuel Mize 1999-06-15 0:00 ` jerry 2 siblings, 1 reply; 120+ messages in thread From: Samuel Mize @ 1999-06-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` Samuel Mize @ 1999-06-15 0:00 ` jerry 1999-06-16 0:00 ` Richard D Riehle 0 siblings, 1 reply; 120+ messages in thread From: jerry @ 1999-06-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-15 0:00 ` jerry @ 1999-06-16 0:00 ` Richard D Riehle 1999-06-16 0:00 ` jerry 0 siblings, 1 reply; 120+ messages in thread From: Richard D Riehle @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-16 0:00 ` Richard D Riehle @ 1999-06-16 0:00 ` jerry 0 siblings, 0 replies; 120+ messages in thread From: jerry @ 1999-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-14 0:00 ` Mark Hood 1999-06-15 0:00 ` mike @ 1999-06-17 0:00 ` Markus Kuhn 1999-06-17 0:00 ` David Botton 1 sibling, 1 reply; 120+ messages in thread From: Markus Kuhn @ 1999-06-17 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-17 0:00 ` Markus Kuhn @ 1999-06-17 0:00 ` David Botton 0 siblings, 0 replies; 120+ messages in thread From: David Botton @ 1999-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-12 0:00 ` Tucker Taft 1999-06-12 0:00 ` PPAATT 1999-06-12 0:00 ` Keith Thompson @ 1999-06-13 0:00 ` Robert Dewar 1999-06-14 0:00 ` tmoran 2 siblings, 1 reply; 120+ messages in thread From: Robert Dewar @ 1999-06-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-13 0:00 ` Robert Dewar @ 1999-06-14 0:00 ` tmoran 1999-06-30 0:00 ` John Merryweather Cooper 0 siblings, 1 reply; 120+ messages in thread From: tmoran @ 1999-06-14 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-14 0:00 ` tmoran @ 1999-06-30 0:00 ` John Merryweather Cooper 1999-07-01 0:00 ` Chad R. Meiners 0 siblings, 1 reply; 120+ messages in thread From: John Merryweather Cooper @ 1999-06-30 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-06-30 0:00 ` John Merryweather Cooper @ 1999-07-01 0:00 ` Chad R. Meiners 1999-07-02 0:00 ` Robert Dewar 0 siblings, 1 reply; 120+ messages in thread From: Chad R. Meiners @ 1999-07-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-07-01 0:00 ` Chad R. Meiners @ 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` John Merryweather Cooper 0 siblings, 1 reply; 120+ messages in thread From: Robert Dewar @ 1999-07-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-07-02 0:00 ` Robert Dewar @ 1999-07-02 0:00 ` John Merryweather Cooper 1999-07-03 0:00 ` Robert Dewar 0 siblings, 1 reply; 120+ messages in thread From: John Merryweather Cooper @ 1999-07-02 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Ada and Java. different behaviour. casting long to int problem. 1999-07-02 0:00 ` John Merryweather Cooper @ 1999-07-03 0:00 ` Robert Dewar 0 siblings, 0 replies; 120+ messages in thread From: Robert Dewar @ 1999-07-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 120+ messages in thread
end of thread, other threads:[~1999-07-20 0:00 UTC | newest] Thread overview: 120+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-12 0:00 Ada and Java. different behaviour. casting long to int problem nabbasi 1999-06-12 0:00 ` nabbasi 1999-06-12 0:00 ` jerry 1999-06-12 0:00 ` Robert Dewar 1999-06-14 0:00 ` Marin David Condic 1999-06-12 0:00 ` Tucker Taft 1999-06-12 0:00 ` PPAATT 1999-06-12 0:00 ` Keith Thompson 1999-06-12 0:00 ` kirck 1999-06-13 0:00 ` Robert Dewar 1999-06-12 0:00 ` Fred 1999-06-14 0:00 ` Mark Hood 1999-06-15 0:00 ` mike 1999-06-15 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Matthew Heaney 1999-06-17 0:00 ` Aidan Skinner 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` Mike Silva 1999-06-15 0:00 ` rich 1999-06-15 0:00 ` Samuel Mize 1999-06-15 0:00 ` Marin David Condic 1999-06-15 0:00 ` D'Arcy Smith 1999-06-15 0:00 ` Keith Thompson 1999-06-16 0:00 ` bill 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` Fraser Wilson 1999-06-17 0:00 ` Chris Dollin 1999-06-17 0:00 ` Aidan Skinner 1999-06-17 0:00 ` David Botton 1999-06-18 0:00 ` Dale Stanbrough 1999-06-18 0:00 ` Matthew Heaney 1999-06-18 0:00 ` David Botton 1999-06-18 0:00 ` Pascal Obry 1999-07-20 0:00 ` Geoff Bull 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` George W. Bayles 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` Tucker Taft 1999-06-17 0:00 ` George W. Bayles 1999-06-17 0:00 ` Tucker Taft 1999-06-17 0:00 ` bob 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Larry Kilgallen 1999-06-16 0:00 ` Marin David Condic 1999-06-16 0:00 ` Mike Silva 1999-06-16 0:00 ` D'Arcy Smith 1999-06-16 0:00 ` kirk 1999-06-16 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` Markus Kuhn 1999-06-17 0:00 ` D'Arcy Smith 1999-06-17 0:00 ` john 1999-06-17 0:00 ` Ed Falis 1999-06-18 0:00 ` Aidan Skinner 1999-06-16 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Robert I. Eachus 1999-06-17 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Marin David Condic 1999-06-17 0:00 ` bob 1999-06-18 0:00 ` Hyman Rosen 1999-06-18 0:00 ` mike 1999-06-18 0:00 ` Hyman Rosen 1999-06-19 0:00 ` Samuel Mize 1999-06-21 0:00 ` Marin David Condic 1999-06-19 0:00 ` Dale Stanbrough 1999-06-21 0:00 ` Marin David Condic 1999-06-21 0:00 ` Mike Silva 1999-06-17 0:00 ` Markus Kuhn 1999-06-17 0:00 ` Jean-Pierre Rosen 1999-06-17 0:00 ` Marin David Condic 1999-06-17 0:00 ` Samuel Mize 1999-06-17 0:00 ` Marin David Condic 1999-06-22 0:00 ` Hyman Rosen 1999-06-22 0:00 ` Keith Thompson 1999-06-23 0:00 ` Marin David Condic 1999-06-24 0:00 ` Robert A Duff 1999-06-24 0:00 ` Marin David Condic 1999-06-23 0:00 ` Marin David Condic 1999-06-18 0:00 ` Aidan Skinner 1999-06-20 0:00 ` Sera Hirasuna 1999-06-19 0:00 ` Kio 1999-06-20 0:00 ` Vladimir Olensky 1999-06-21 0:00 ` Samuel T. Harris 1999-06-22 0:00 ` Robert I. Eachus 1999-06-23 0:00 ` Aidan Skinner 1999-06-23 0:00 ` Richard D Riehle 1999-06-22 0:00 ` Richard D Riehle 1999-06-21 0:00 ` Hyman Rosen 1999-06-17 0:00 ` Jean-Pierre Rosen 1999-06-22 0:00 ` Robert Dewar 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Vladimir Olensky 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Roedy Green 1999-06-23 0:00 ` Marin David Condic 1999-06-23 0:00 ` Keith Thompson 1999-06-24 0:00 ` Marin David Condic 1999-06-24 0:00 ` Mike Silva 1999-06-15 0:00 ` tmoran 1999-06-15 0:00 ` David Botton 1999-06-16 0:00 ` Samuel Mize 1999-06-16 0:00 ` Richard D Riehle 1999-06-16 0:00 ` Mark Hood 1999-06-17 0:00 ` Jean-Pierre Rosen 1999-06-17 0:00 ` Robert I. Eachus 1999-06-17 0:00 ` Marin David Condic 1999-06-15 0:00 ` Samuel Mize 1999-06-15 0:00 ` jerry 1999-06-16 0:00 ` Richard D Riehle 1999-06-16 0:00 ` jerry 1999-06-17 0:00 ` Markus Kuhn 1999-06-17 0:00 ` David Botton 1999-06-13 0:00 ` Robert Dewar 1999-06-14 0:00 ` tmoran 1999-06-30 0:00 ` John Merryweather Cooper 1999-07-01 0:00 ` Chad R. Meiners 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` John Merryweather Cooper 1999-07-03 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox