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: 103376,e6a2e4a4c0d7d8a6
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-02-26 10:57:08 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail
From: Stephen Leake <Stephen.A.Leake@nasa.gov>
Newsgroups: comp.lang.ada
Subject: Re: status of PL/I as a viable language
Date: 26 Feb 2003 13:49:09 -0500
Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov)
Message-ID: <uadgi6foa.fsf@nasa.gov>
References: <mHZ0a.42983$jM5.108891@newsfeeds.bigpond.com>
 <nRg1a.190899$HG.32437469@news4.srv.hcvlny.cv.net>
 <3E51908E.9CCA3412@adaworks.com>
 <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net>
 <3E51ABCE.5491B9A2@adaworks.com> <b2spe6$p23$1@helle.btinternet.com>
 <3E5273DE.2050206@cox.net> <3E531E6F.BDFB2599@adaworks.com>
 <3E546C45.4010406@cox.net> <3E54F926.441D5BB5@adaworks.com>
 <1045763933.848350@master.nyc.kbcfp.com>
 <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net>
 <1045769690.126389@master.nyc.kbcfp.com> <2lb33b.7d6.ln@jellix.jlfencey.com>
 <1045772065.590669@master.nyc.kbcfp.com> <oprkxqhntnmzo9uz@news.vol.cz>
 <1045839283.86671@master.nyc.kbcfp.com> <v5d4ecdfopogde@corp.supernews.com>
 <slrnb5embn.le.randhol+news@kiuk0152.chembio.ntnu.no>
 <v5kv6ub5oj0299@corp.supernews.com>
 <slrnb5mfjo.o4.randhol+news@kiuk0152.chembio.ntnu.no>
NNTP-Posting-Host: anarres.gsfc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: skates.gsfc.nasa.gov 1046286183 27894 128.183.235.92 (26 Feb 2003
 19:03:03 GMT)
X-Complaints-To: usenet@news.gsfc.nasa.gov
NNTP-Posting-Date: 26 Feb 2003 19:03:03 GMT
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Xref: archiver1.google.com comp.lang.ada:34616
Date: 2003-02-26T19:03:03+00:00
List-Id: <comp.lang.ada>

Preben Randhol <randhol+news@pvv.org> writes:

> Randy Brukardt wrote:
> > In order to avoid dynamic allocation of commands, I put the parsed
> > commands into a record type with a bunch of statically bounded strings.
> > These have to be carefully handled for overflow, and there were a couple
> > of obscure cases where I got it wrong. Of course, nothing bad happened,
> > I just got a logged Constraint_Error and the command was aborted. (Since
> > the problems all came from people trying to break in, I wasn't even
> > particularly upset that they weren't served...)
> 
> So in reality it wasn't a buffer overflow as Ada caught it, 

I think the English meaning of the term "buffer overflow" is clear;
the program tried to write more data to the buffer than it had room
for.

> while if it had been in C you would have had a buffer overflow and
> possibly people breaking in. 

The _consequences_ of the buffer overflow are different in C and Ada;
in Ada the overflow is caught, and handled in a way that does not
allow security breaches.

In poorly programmed C, the buffer overflow is not caught, and does
(possibly) allow security breaches.

> Did I understand it correctly?

Not quite: it really is a buffer overflow :).

I suppose the term "buffer overflow" has been overloaded to mean
"buffer overflow that allows security breaches". But in this context,
I think the more narrow meaning is appropriate.

-- 
-- Stephe