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,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-06 17:07:07 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: <3B6F312F.DA4E178E@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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 07 Aug 2001 00:07:06 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 997142826 24.141.193.224 (Mon, 06 Aug 2001 17:07:06 PDT) NNTP-Posting-Date: Mon, 06 Aug 2001 17:07:06 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:11428 comp.lang.c:72589 comp.lang.c++:80489 Date: 2001-08-07T00:07:06+00:00 List-Id: Bart.Vanhauwaert@nowhere.be wrote: > Warren W. Gay VE3WWG wrote: > > Array bounds as you need them (C/C++ and Java still insist that you start > > at zero and work up). (PL/I could have different bounds too). > > This seems a minor advantage. In fact, I consider the uniformity > and advantage. Less possibility for off by one errors (did they start > at 0 or at 1? I am too lazy to check, let's just assume 1, etc) Well, what can I say? Others consider it to be at least a two-fold advantage: 1) They can write the code with the array bounds that directly maps to the algorithm in question. 2) The reader of the code can easily understand the code also, because the array bounds match the description of the algorithm. 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). So, if this is minor to you, then so be it. > > No need to know pointer context (C/C++ require obj.attr or obj->attr > > depending upon what you have). The Ada compiler knows hows to do > > obj.attr regardless of the context. > > Again, minor advantage. The compiler will warn you if you make mistakes. Yes, this is "minor", but it is "more convenient", which was my point. > > Records with discriminants : Ada lets you define records (structs) with > > varying size, according to the discriminant. C/C++ still must define > > a char [1], and purposely work outside the array bounds to suit. For > > an example, look at man msgsnd(2) (msgsnd(3) on BSD). They use the > > 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. > > String form of enumerated values (in Ada), upon demand. In C/C++, you > > must provide this for yourself. (ie. if you have C enum { Idle, > > Waiting, Running } e; How do you print out the string > > representation of e?) > > 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. > > Array slice assignment and comparison (in Ada). In C/C++, you must code > > this for yourself, in loops etc. In Ada, you can assign array slices > > as in A_Array(1..3) := B_Array(5..7). In C/C++, you'd have to depend > > upon a function, or code a loop. > > 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 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. > > Attributes in Ada (like My_Array'Length). In C/C++ you must mess with the > > sizeof operator (which can fool you with physical size instead of logical > > size), or code it yourself with macros (constants in Java). > > 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, 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. > If you mean padding, it is a well > understood phenomena. Anyone writing programs where padding matters, > knows enough to understand the documentation of his/her compiler > to straighten such issues out. Re: "sizeof" : 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! This problem is simply unnecessary, and one where the C/C++ compiler is of no help. > > And Ada does much much more ;-) > > How'd I go about creating a M$-alike desktop application (after all, > there is no arguing that is the largest market for software)? > Time gains of being able to directly (re)use large codebases that > certain (popular) platforms offer for example are more > important than all your arguments mentioned above. > While I am certain that Ada has bindings for some platform > functionality, I am also certain they are not as complete as > those for C/C++. Well, now you have switched to a "market presence" argument, which I won't argue with. I was only illustrating a few points of "convenience" that Ada provides. Others can respond to your marketing presence, if they feel inclined. > Sure, if you are doing a defense job, it could be that the platform > you need is better developed in Ada. But proposing Ada now as > _the_ best solution on the basis of some (not very convincing imho) > situations where ada simplifies development, is plain and simple > taking one's wishes for granted. > > cu bart 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. ;-) -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg