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: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-07 19:59:29 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc2.on.home.com.POSTED!not-for-mail Message-ID: <3B70AB15.35845A98@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> <3B6F312F.DA4E178E@home.com> <23lok9.ioi.ln@10.0.0.2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 02:59:28 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 997239568 24.141.193.224 (Tue, 07 Aug 2001 19:59:28 PDT) NNTP-Posting-Date: Tue, 07 Aug 2001 19:59:28 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:11566 comp.lang.c:72814 comp.lang.c++:80831 Date: 2001-08-08T02:59:28+00:00 List-Id: Bart.Vanhauwaert@nowhere.be wrote: > Warren W. Gay VE3WWG wrote: > > Well, what can I say? Others consider it to be at least a two-fold > > advantage: > > Let's just call it taste. Fine. > > And BTW, knowing the array bounds is not a problem. That is why Ada > > provides convenient attributes like My_Array'First and My_Array'Last > > (PL/I did it with builtin functions like lbound(My_Array) and hbound(My_Array) > > IIRC). > > And as we all know, lazy programmers will not use 'First and 'Last, > but will assume it's 0. You don't know Ada, nor Ada programmers very well do you? :-) As someone else kindly pointed out, if they were to "assume", they'd assume 1! But that is not likely anyway, since any Ada newby already knows about all those convenient attributes that the compiler freely provides without error. > >> In C++ you just use virtual member funcs. Or template functions if > >> speed is primordial. Easier, cleaner. Comparable mechanisms exist > >> in C. > > Virtual functions do not address this issue. You clearly do not understand > > the problem here. > > Well, why don't you explain the problem than? (In a modern C++ program > the only need for variants is interfacing with legacy API's btw) Go back and read the first post. Then actually spend some time writing a test program that actually sends different sized messages with msgsnd() and msgrcv(). Obviously, you've never used these in any language, or you would already know the problem. ;-) > >> Minor advantage. Totally ofset by the fact that serious software needs > >> internationalization anyway. If really needed, a gross #define hack > >> does the trick. > > You said it best -- "gross". ;-) It is also "error prone", which is one > > reason why Ada makes this service available. > > And you left out the beef of my argument of course : real software > needs internationalization anyway, rendering this feature totally > useless. Ada95 does provide facilities for internationalization. But even if the Enum_Type'Image() facility only comes in ASCII? That doesn't prevent it from being useful, does it? You're grasping at straws on this one ;-) > >> Read up on the STL. It does that and more (like sticking a transformation > >> in between, copying from stdin directly to a slice, etc...) > > The STL is not used in all contexts (it's just not practical). If you call > > The STL is practical and in use in major projects. Read my response again. I said the "STL is not used in all contexts". I never said that it not used in all projects as you seem to be replying to. In other words, in a given project, with or without the STL, there will be arrays of one type or another, that exist naked without the helpful bounds checking of a STL class. The pipe(2) system call was a simple case where this could occur. This is by no means exclusive ;-) > > pipe(2), you will not be using a vector from the STL. You'll use a naked > > int[2] array. This is only one example. > > That's why the STL has special provisions to deal with legacy C-style > arrays. > > Recommended reading for you : (I am sure you'll find it on amazon) I have used the STL and even have books on it, thank you. I know its weaknesses too, and I have since repented ;-) > The C++ Standard Library -- A tutorial and reference > Nicolai M. Josuttis, Addison Wesley Longman > > >> Again, this seems mostly syntactical sugar. I don't understand the > >> physical/logical argument. > > Exactly.. you don't have it in C/C++, so you don't understand its advantages. > > I don't mean to be condescending in that, just that you are used to defining > > macros to do the same work. But this is something you should not have to do, > > I have never felt the need to know the size of a certain struct. Why > don't you give an example where it is needed? What? You've never written a structure to a file? A socket? A message queue? > > since it is error prone, and adds unnecessary "software clutter". Let the > > computer do what it does best -- keep track of the implementation details. Ada > > does precisely that. > > I prefer a programming style where implementation details don't matter > so that the code is portable. Which is why it should be the compiler's job. You said it yourself. The implementation details should not matter to you. I agree with this. But programmers can't reliably take this responsibility. Compilers are better at it (they don't get tired, sleepy or even grumpy.) > > They often don't get it right the first time. Sure experienced developers > > eventually learn this. But I've seen this mistake made regularly by > > people who work in C/C++ every day. What's worse, is that a developer > > may code a sizeof expression that happens to work for his current > > platform X. Then when the code is ported to platform Y where the > > padding is different -- SURPRISE! Porting problem! > > I write code that runs on windows/unix for living. I just grepped through > my current project (rather small, 500k lines) there is not one single > sizeof in the code. That kind of proof won't get very far. That's like trying to prove a hypothesis with a limited emperical evidence. Anyone scrutinizing this kind of response, simply has to ask "So?" > > BTW, this orignal post was not meant to be the reasons "Ada is best". The > > posted comments are "these are some conveniences of Ada". If I wanted > > to do a "sales job" for Ada, I would not start with these points, nor > > use these alone. There are so many better reasons for using Ada. ;-) > > Well, let's bring them to the table then! A bit of valuable discussion > in a thread full of trolls won't hurt anybody. In case you havn't noticed, there has been some other threads very active in this regard (or at least in comp.lang.ada). I'm not going to repeat all of that here ;-) You can find them on your own time. -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg