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: 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-07 20:14:49 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!headwall.stanford.edu!feeder.via.net!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc2.on.home.com.POSTED!not-for-mail Message-ID: <3B70AEAE.1CB62063@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> <3B69DB35.4412459E@home.com> <9kp9n7$ivm$1@nh.pace.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 03:14:48 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 997240488 24.141.193.224 (Tue, 07 Aug 2001 20:14:48 PDT) NNTP-Posting-Date: Tue, 07 Aug 2001 20:14:48 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:11568 comp.lang.c:72816 comp.lang.c++:80832 Date: 2001-08-08T03:14:48+00:00 List-Id: Marin David Condic wrote: > > And don't forget 'Range - very useful for "for" loops. And the same thing > works with multiple dimensions as in Some_Array'First (1) or > Some_Array'Range (2) or Some_Array'Length (N). What is really useful here is > that if you avoid coding things with hard references into the array, you can > pretty much leave the code untouched if/when you make any changes to the > sizes/indexes of the array. Yes, this is _very_ cool. I change buffer sizes to provoke different tests in code where there might be buffer size issues. All it takes is one central change, where the array is declared. Like you've pointed out, the entire rest of the project then adjusts as is necessary. > It gets even more useful when trying to write > generic array utilities or utilities that can deal with a *slice* of an > array. (Like: "Some_Procedure (Some_Array (6..23)) ;" - if the internals use > the attributes, it works nicely for any slice.) > > In general the attributes are *very* handy because they provide information > that the compiler just automatically knows about and can use so that things > are not hard coded. To some extent you can do this in C/C++ by defining your > own constants or functions but ultimately a change to the data structure > means revisiting this code - possibly missing something. Not only that, there is a chance that when macros are used, that a macro can be silently #undef and redefined differently. In larger projects, this is a real possibility and it happens. People tend to re-use the same names! > With Ada, a change > to the data structure should just take care of itself as long as you use the > attributes. (Of course, there isn't anything to stop you from hard-coding > things in Ada as well - but if you hose it up, at least you'll get a > compiletime or runtime error letting you know you did that.) > > MDC To be fair, not all hard-coded references will be compile time errors (if they currently fall within the current acceptable bounds of that array). However, I agree that if "you hose it up", then you bear the responsibility of the consequences. No language is going to protect you totally from poor practices. But the compiler will point out the hard-coded reference should the array bounds change in a later revision of the code, that makes it illegal. Also an exception will be raised due to slicing (in a procedure/function call), if the slice range falls outside of the hardcoded value (1 likely). -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg