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-04 07:12:51 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!148.122.208.68!news2.oke.nextra.no!nextra.com!news3.oke.nextra.no.POSTED!not-for-mail From: "Tor Rustad" Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional References: <9k9if8$rn3$1@elf.eng.bsdi.com> <3B687EDF.9359F3FC@mediaone.net> <5267be60.0108021911.7d8fe4@posting.google.com> <3B6B637F.E3FA243E@worldnet.att.net> Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: NNTP-Posting-Host: 148.122.147.228 X-Complaints-To: news-abuse@nextra.no NNTP-Posting-Date: Sat, 04 Aug 2001 16:12:45 MEST Organization: Nextra Public Access X-Trace: news3.oke.nextra.no 996934365 148.122.147.228 Date: Sat, 4 Aug 2001 16:07:49 +0200 Xref: archiver1.google.com comp.lang.ada:11291 comp.lang.c:72100 comp.lang.c++:79911 comp.lang.functional:7298 Date: 2001-08-04T16:07:49+02:00 List-Id: "James Rogers" wrote in message > Tor Rustad wrote: > > > > IMHO, using 16-bit integers, is also a design issue. If there was strict > > performance requirements to be met, well then why not use a faster > > programming language, where the programmers perhaps could afford to use > > 32-bit integers? Even in non-critical systems, I do think that many > > There is no such thing as a faster programming language. Certain > compilers may produce faster code. Some compilers allow you to select > optimization for a balance of speed and code size. These optimizations > are not a language issue. They are compiler implementation issues. Not quite, when using a language which has built in security mechanisms on a target which doesn't support these features natively (in HW), then there will simply be a performance penalty. It may be significant, or it may very well not be. In this case, perhaps it was? > Just ask yourself. "How fast is C? How Fast is C++?" There is no > answer to that question. Speed is not specified in any language > reference manual. Yes, comparing C vs C++ can be silly, more so when the code have identical syntax. In the Ariane case, there was particular target (HW plattform), I am shure there was performance differences between using different languages/compilers/optimizers for this target. Write a "Hello world!" program in Java, and name one single case for which my C version will run slower. ;-) In real life the language used do matter, so does the algorithms, compiler and optimizer for that matter. Some langages support performance contructs, e.g. in C99 we have const, restrict and volatile keyword, which let the programmer control optimizations at low level. An other example is the floating point conversion rules in C, which may give rather poor floating-point performance (compared to for example a Fortran program), but it depends on the target etc. -- Tor "The practical scientist is trying to solve tomorrow's problem with yesterday's computer; the computer scientist, we think, often has it the other way around.", - NR on float conversion rules in C89