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-Thread: 103376,5bc4be576204aa20 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Peter Amey Newsgroups: comp.lang.ada Subject: Re: Buffer overflow Article - CACM Date: Mon, 14 Nov 2005 10:17:21 +0000 Message-ID: <3tr6hiFu7jr6U1@individual.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net jPJADRuK8GfInGhOY49ZMQBrPE0DrKXplK2WFnuIIbVgZIOEw= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:6373 Date: 2005-11-14T10:17:21+00:00 List-Id: Jeffrey R. Carter wrote: > adaworks@sbcglobal.net wrote: > [snip] > > Then they say that bounds checking adds 100% overhead. This may be true > of trying to patch C, but it's certainly not true of all the checks Ada > does, which is much more than simply bounds checking. In practice I have > never found a case in which leaving checks in was too slow, nor where > turning them off saved more than 10%. > OF course, using SPARK, we can statically prove the absence of buffer overflows (and many other potential exploits) and thus add precisely nothing in the form of a run-time overhead! Peter