From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,fee8802cc3d8334d X-Google-Attributes: gid10a146,public From: Tucker Taft Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/16 Message-ID: <3767DF5C.5C4A79A@averstar.com>#1/1 X-Deja-AN: 490331207 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <7jt2c0$vrb@drn.newsguy.com> <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com> <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com> <3766C842.E1EAB60A@pwfl.com> <3766D1CC.D712895E@itools.symantec.com> <3767CDFC.798BBB23@cajunbro.com> Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.java.programmer Date: 1999-06-16T00:00:00+00:00 List-Id: 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 > [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