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: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-03 02:21:47 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!195.64.68.27!newsgate.cistron.nl!news.worldonline.nl!bnewspeer01.bru.ops.eu.uu.net!lnewspeer01.lnd.ops.eu.uu.net!lnewspost00.lnd.ops.eu.uu.net!emea.uu.net!not-for-mail Message-ID: <3B6A6E8A.7D254E26@isltd.insignia.com> Date: Fri, 03 Aug 2001 10:27:38 +0100 From: Christian Bau Organization: Insignia Solutions plc X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 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. References: <3B687EDF.9359F3FC@mediaone.net> <3B6A588C.B67A9CF8@isltd.insignia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cache-Post-Path: macallan.isltd.insignia.com!unknown@tigger.isltd.insignia.com X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) NNTP-Posting-Host: macallan.isltd.insignia.com X-Trace: 996830505 reading.news.pipex.net 3760 195.217.222.21 X-Complaints-To: abuse@uk.uu.net Xref: archiver1.google.com comp.lang.ada:11180 comp.lang.c:71856 comp.lang.c++:79605 comp.lang.functional:7248 Date: 2001-08-03T10:27:38+01:00 List-Id: Daniel Fischer wrote: > > > 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. > > 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 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. > > (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. 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?