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 01:06:09 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!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 10:02:32 +0200 Organization: Gueldenland MUD: telnet gl.mud.de 4444 Message-ID: References: <3B687EDF.9359F3FC@mediaone.net> <3B6A588C.B67A9CF8@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 996825756 07 30910 l+QoS+iXSvY4Jh 010803 08:02:36 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:11175 comp.lang.c:71843 comp.lang.c++:79592 comp.lang.functional:7246 Date: 2001-08-03T10:02:32+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. > Why was there no "protection against operand errors"? In other words, > why was there no code that would detect the error, take appropriate > action against the error, and continue flying the rocket? You didn't even read the report. There was no such code in this place because there originally was a requirement that only 80% of cpu time could be used, so they dropped some of the checks. > I think any explicit check for this overflow and trying to handle it > would have been inappropriate. It was (incorrectly) determined that an > overflow could not happen, so there was no appropriate action possible. 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 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). The results were not used because there were no results. The overflow apparently triggered a hardware exception. Since it was determined that only a hardware defect could cause such an exception, the unit shut itself down. As did the backup because it got the same data. Daniel -- IMO, anyway. end message by (Daniel Fischer ) clc FAQ: http://www.eskimo.com/~scs/C-faq/top.html 08/03 Memorial Day of Archbishop Makarios in Cyprus