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: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-06 19:50:11 PST Path: archiver1.google.com!newsfeed.google.com!postnews1.google.com!not-for-mail From: mjsilva@jps.net (Mike Silva) 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 ofservice attack. Date: 6 Aug 2001 19:50:11 -0700 Organization: http://groups.google.com/ Message-ID: <5267be60.0108061850.6395c5b2@posting.google.com> References: <3B6555ED.9B0B0420@sneakemail.com> <87n15lxzzv.fsf@deneb.enyo.de> <3B672322.B5EA1B66@home.com> <5ee5b646.0108010949.5abab7fe@posting.google.com> <3B6CD64F.E96911F8@yahoo.com> <9kmd5a$euq$1@nh.pace.co.uk> NNTP-Posting-Host: 209.239.210.192 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 997152611 19591 127.0.0.1 (7 Aug 2001 02:50:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 7 Aug 2001 02:50:11 GMT Xref: archiver1.google.com comp.lang.ada:11438 comp.lang.c:72606 comp.lang.c++:80516 comp.lang.functional:7373 Date: 2001-08-07T02:50:11+00:00 List-Id: Had that exact thing happen to me just last week, where some code for a new piece of hardware decided to fill in a structure intended for an old piece of hardware, and ended up trying to stuff 6 quarts into a 4 quart jug. Spent half a day finding the problem. Chalk up one more for my ongoing "wouldn't have happened in Ada" list! Mike "Marin David Condic" wrote in message news:<9kmd5a$euq$1@nh.pace.co.uk>... > Or someone redefined you #define somewhere between when you declared your > array and when you called the function. Never happens? What about when you > start bringing in header files with the #include? How many times do > programmers use names like "MAXSIZE" or "BUFFSIZE" or similar? How about > really big files with dozens or hundreds of functions in them? Its *way* > easy to get that kind of error into a program. > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > Web: http://www.mcondic.com/ > > "CBFalconer" wrote in message > news:3B6CD64F.E96911F8@yahoo.com... > > David Lee Lambert wrote: > > > > ... snip ... > > > > > > In C, one has to think ahead a little in some situations, but it's > still > > > quite straightforward to write overflow-free code once one has been > > > introduced to the right functions: fgets(), snprintf(), (non-ANSI) > > > strlcpy()... > > > > Oh, how about: > > > > #define BUF1SZ 10 > > ... > > #define BUF2SZ 20 > > ... > > char buff1[BUF1SZ] > > ... > > fgets(buf1, BUF2SZ, stdin); > > > > and I have no idea where the error will hit. The equivalent in > > any range checking language will hit at the read, if not at the > > compile. Before you say the programmer shouldn't have done that, > > consider the thousands of lines that may be represented by the ... > > and that the statements may even be in different files. > >