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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107f24,582dff0b3f065a52 X-Google-Attributes: gid107f24,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-03 03:06:09 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!grolier!newsfeed00.sul.t-online.de!newsmm00.sul.t-online.com!t-online.de!news.t-online.com!not-for-mail From: "Daniel Fischer" Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Date: Fri, 03 Aug 2001 12:01:58 +0200 Organization: Gueldenland MUD: telnet gl.mud.de 4444 Message-ID: References: <3B687EDF.9359F3FC@mediaone.net> <3B6A588C.B67A9CF8@isltd.insignia.com> <3B6A6E8A.7D254E26@isltd.insignia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.t-online.com 996832923 02 29559 OuBoS31XSVY1RT 010803 10:02:03 X-Complaints-To: abuse@t-online.com X-Sender: 520060923510-0001@t-dialin.net User-Agent: Pan/0.9.7 (Unix) Xref: archiver1.google.com comp.lang.ada:11182 comp.lang.c:71859 comp.lang.c++:79614 comp.lang.functional:7249 Date: 2001-08-03T12:01:58+02:00 List-Id: Hi, - followup ("Christian Bau" ) >> > Since this thread is about comparing C or C++ and Ada: If the >> > software had been written in C, C++ or Java, the result would have >> > been a completely wrong integer result. For example, casting a value >> > of 40000.0 to a 16 bit signed int will give a strange result of >> > -25536. (In Java, this is defined behaviour. In C or C++ this might >> > be undefined or implementation defined; in practice the result will >> > most likely be -25536). >> >> Nowhere in the report it says "cast". There are appropriate functions >> in C and family for conversions of floating point values to integers. > > In C, the operation of converting a floating point value to a value of > integral type is called a "cast". If they call it different in Ada I > couldn't care less. I would say this demonstrates that you have a very > limited ability of abstraction. Says someone who states: > For example, casting a value of 40000.0 to a 16 bit signed int will give > a strange result of -25536. In C, the operation of explicitly coercing a floating point value into a value of an integral type is called a cast. The result is undefined if the value is outside of the range of the result type. Undefined *includes* an "operand error", and it also allows for demons to fly out of your nose. There really is no difference between Ada and C here. In C, there are also conversion functions (such as lrint) that *can do* range checking. The report does *not* contain any hint as to the ada version of a cast being used. It could as well have been the ada version of such a function. >> You didn't even read the report. The decision that an overflow could >> not happen was correct, as the code was written for the Ariane 4 where >> values that would cause the conversion to overflow are indeed >> impossible. The problem was that this fact was somehow lost and nobody >> remembered it when they decided to use the same code for the Ariane 5. > > This is plain stupid. If code for Ariane 4 is used on Ariane 5, and an > assumption that was true on Ariane 4 is false on Ariane 5, then this is > assumption is false. The assumption that no overflow could happen became > wrong when the code was reused. The assumption that no overflow could happen with Ariane 4 is still true, even if Ariane 5 was lost due to it. The program was never meant to control Ariane 5. The mistake was not the assumption that no overflow could happen but the decision to use the software for a job it was never meant to do. >> > (This is assuming that the results were indeed used. If there is >> > functionality in a rocket that is not related to its performance, >> > like sending data to the ground, and a malfunction in this is >> > detected, then ignoring that malfunction might be the better action). > I think you must be deliberately trying to misunderstand what I wrote. > Yes, if an overflow check makes it impossible to ever use an incorrect > results then incorrect results will not be used. The question is: Would > the result have been used if an overflow had not been detected? I believe you must be misunderstanding yourself. This is a meaningless question if the hardware or the implementation of the ada language makes it impossible not to detect overflow errors, as is the case here. Also, ignoring *any* malfunction is not a good choice. You can do that on a personal computer, but not on a rocket where *any* malfunction can mean that something is seriously messed up. Shuting down a malfunctioning subsystem is the *only* choice here. Daniel -- IMO, anyway. end message by (Daniel Fischer ) clc FAQ: http://www.eskimo.com/~scs/C-faq/top.html 08/03 Funeral of King Theoden (LOTR)