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: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-09 17:23:55 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!worldnet.att.net!24.0.0.38!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc2.on.home.com.POSTED!not-for-mail Message-ID: <3B7329A2.959E04B4@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> <3B722166.AFBFE73A@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 10 Aug 2001 00:23:54 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 997403034 24.141.193.224 (Thu, 09 Aug 2001 17:23:54 PDT) NNTP-Posting-Date: Thu, 09 Aug 2001 17:23:54 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:11728 comp.lang.c:73293 comp.lang.c++:81407 Date: 2001-08-10T00:23:54+00:00 List-Id: Bart.Vanhauwaert@nowhere.be wrote: > Warren W. Gay VE3WWG wrote: > >> I am not really sure where this is fundamentally different from > >> for (std::vector::iterator i=v.begin(); i!=v.end(); ++i) > >> ... > >> and > > Yes, but your STL classes cannot help you to deal with regular arrays. In Ada, > > these attributes work on _any_ array. Not just ones cooked up by your STL > > classes. > > Doctor it hurts if I do this. Well, don't do that then! Don't use > arrays, use std::vector. I'm not going to puff into the wind any more on this. Believe what you want to, but your experience does not agree with mind. We'll just leave it at that. > > Fixed sized arrays occur all the time. When you fill out tax forms, > > medical forms, drivers license forms, are not all the spaces fixed > > in length? Fixed lengths occur all the time in programmed systems > > as well. > > Well, I'd certainly NOT use a fixed length array for things you > are likely to find on tax forms/medical forms/... Yes, i'd check > validity at form entry (number of digits, format, etc) But > i'd store it as a free form unlimited length string. So when you do a FETCH from an relational database, into a string column value, you're going to use a dynamic array? What initial size are you going to specify? I think you already know that fixed arrays do get used, but you just don't want to recognize it here. So I'll just leave you with this last example. > Because it might be easy to change is array(1..12) of character > to is array (1..13) of character. An indeed if you meticously used > 'Length everywhere no problem. But Ada programmers are a "meticulous bunch". They have to be, because the compiler is. Anyway, it does not require meticulous habits to make use of extremely useful features like 'Length, 'First or 'Last. Certainly less effort than it is to use your macros, or sizeof expressions for the same thing. ;-) > But once you start thinking this > was it ends up in your protocols (oeps, lucky we had some > reserved(1..12) of character at the end of our message!), in > your file formats, etc.. where the real problems are. APIs and protocols often have fixed sizes in them. Sheesh, where have you been? Have you looked at TCP/IP headers for example? > > Even when "length" is not fixed, often the maximum is. I know > > the point you're making, but its not justified here. For example, > > pipe(2) is not going to have a problem with an array of 2 file > > descriptors in an int[2] array. It's never going to return more > > than 2. No need to make a conspiracy out of it ;-) > > You know, you can still put those file descriptors in a std::vector > and do > > pipe(&my_vector[0]); OK, but will your junior programmer you just hired do that? Really? Once again, you are relying on people to do the right thing. And in this case, its still not clear that its the "right thing" anyway, as you freely admit. > (Yes technically, the wording of the current C++ standard is not clear > enough, but there is a defect report that rectifies this; it works > for all current implementations of the STL already in anticipation > of this correction) That kind of assumption will "not fly" on rockets, aircraft or space stations. It should not be the kind of assumption that runs mutual fund companies, banks or insurance companies either. > But the origin of this discussion was uses of 'Length operators and > such. If it is only viable for arrays passed to pipe(2), well... > That's little value isn't it? You've not been listening, obviously. One last time: In Ada there is no reason to shy away from arrays. Additionally, as Ted Dennison has already pointed out in another thread, you are not stuck with rigid array sizes anyway. If you know that you need an array of length N, then just like C++, you can declare a new block with the array of the required length. Ada then makes sure that you use the natural construct "the array" correctly. OTOH, C++ requires you to enlist the help of a library to ensure safety instead. This is where the comparison boils down to its minimum elements. I hope this helps, because there is not much more I can add to this ;-) -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg