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: 103376,bc1361a952ec75ca
X-Google-Attributes: gid103376,public
X-Google-Thread: 109fba,582dff0b3f065a52
X-Google-Attributes: gid109fba,public
X-Google-Thread: 1014db,582dff0b3f065a52
X-Google-Attributes: gid1014db,public
X-Google-ArrivalTime: 2001-08-05 16:25:32 PST
Path: 
 archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!crtntx1-snh1.gtei.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)
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: 5 Aug 2001 19:22:53 -0500
Organization: LJK Software
Message-ID: <oUlfbxsKs1+d@eisner.encompasserve.org>
References: <bebbba07.0107292308.d1192fc@posting.google.com>
 <9k9if8$rn3$1@elf.eng.bsdi.com> <GHEt6A.BzD@approve.se>
 <3B687EDF.9359F3FC@mediaone.net> <GHFDJp.G7q@approve.se>
 <slrn9mi1q3.7kb.randhol+abuse@kiuk0156.chembio.ntnu.no>
 <PNha7.3185$e%4.96222@news3.oke.nextra.no>
 <5267be60.0108021911.7d8fe4@posting.google.com>
 <cOHa7.3620$e%4.107328@news3.oke.nextra.no>
 <3B6B637F.E3FA243E@worldnet.att.net>
 <xpTa7.3738$e%4.109789@news3.oke.nextra.no>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 997053342 305 192.135.80.34 (5 Aug 2001 23:15:42
 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Sun, 5 Aug 2001 23:15:42 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:11332 comp.lang.c:72339
 comp.lang.c++:80167 comp.lang.functional:7324
Date: 2001-08-05T19:22:53-05:00
List-Id: <comp.lang.ada>

In article <xpTa7.3738$e%4.109789@news3.oke.nextra.no>, "Tor Rustad" <torust@online.no.spam> writes:
> "James Rogers" <jimmaureenrogers@worldnet.att.net> 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.

If you aspire to compare the speed of two languages, you must do so
for equivalent programs.  That means, at the gross level:

	Compare a default Ada program to a C program that has
		hand-coded checks everywhere Ada inserts checks.

   or:
	Compare a default C program to an Ada program which has
		checks suppressed.

Otherwise the features of the two programs are not the same.