Re: How Ada could have prevented the Red Code distributed denial of service attack.

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Bart.Vanhauwaert@nowhere.be wrote:
> Warren W. Gay VE3WWG <ve3wwg@home.com> 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