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

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

Chris Wolfe wrote:
> "Warren W. Gay VE3WWG" wrote:
> >
> > > Egad... my compiler's fictional! I suppose C and C++ _cannot_
> > > provide garbage collection either? Or automatic serialization, or
> > > range-checked arithmetic types, or anything else that the
> > > compiler writer decides to include.
> >
> > Well, tell us just _what_ compiler you are using, and just how it
> > addresses the identified issues. You have done neither :)
> 
> You stated: "C/C++ _cannot_ provide [runtime checks like boundary
> checks]"
> This is false. The compiler I am using is a proprietary one, but..

He he, but the one you are _using_ - does it provide array bounds
checking?  Does it throw an exception when your integer or unsigned
type overflows? I expect not. 

> with a search on Google for C AND "array bounds checking" I found
> a list of public ones (including a patch for GCC).

That's just peachy. But a sampling of the population of C++
users using these, ahem, extensions, are likely to be a small portion
of all C++ users.

I suppose you're simply offended by the "_cannot_" remark. Yes, I
suppose that it _is_ possible for a C++ compiler to generate runtime
checks, and even do some limited compile time static checks. But that
is not the general experience.

> Automatic serialization, range-checked arithmetic types and
> garbage collection are a sampling of other features I have run
> across in C-like compilers.

"Run across" is different than saying "I can depend upon ____". In
Ada, you can depend upon the features mentioned. If not, it ain't 
Ada. Ada has a compiler validation suite for this purpose.

> > > It does not require any overwhelming work to convert an Ada
> > > program directly into a functionally identical C++ program using
> > > appropriate (non-standard) templates.
> >
> > We're we talking about doing "conversions"? Let's stick to the
> > discussion here, if you want to respond to "points made".
> 
> By definition, C++ (or C, or assembler) is capable of expressing
> any concept that Ada is capable of.
> 
> My assertion is that the capabilities of C++ make possible a
> library that is semantically identical to Ada's. Hence, using
> appropriate (non-standard) templates, it does not require
> overwhelming work to convert an Ada program directly into a
> functionally identical C++ program.

This is another "take my word for it testimonial here". I will
grant that C++ is a general purpose language, and is quite capable of 
solving any general compuational problem. Ada likewise can solve the
same set of problems. But was not where the discussion was.

We were discussing how well a given language and compiler can solve
problems. Not that they could. That is already a given, since there'd
be no need to compare them if this were not already true.

> > > Amazingly these templates
> > > also tend to spawn safe versions of the standard C functions.
> > > What was that drivel about pipe again?
> >
> > Spawn? Templates?  Show us how this solves the problems identified,
> > and maybe we'll be enlightened. Again.. no substance to your post :)

> // Implement safe completely dynamic array here
> template <class T> class Array { ... };

Ok, you can build classes to do array work. In Ada, this is totally
unnecessary for the same level of safety (the safety is inherent
in the language).  But my point was, that you won't use this array
when interfacing to pipe(2). You can, and _you_ might, but a lot
of C++ people will not.

> class Posix
> {
> // ...
>   // Safe pipe, as Array checks bounds
>   int pipe(Array<int> &);
> // ...
> };

This very well and good. You defined a class to interface with the
pipe(2) call. Now, if every C++ programmer _always_ did it this way
(or some safe way),
and _always_ implemented it correctly, for all POSIX interfaces 
that were used, that present this type of problem, 
_then_ you might have a point with this solution.

But in reality, if I were to audit any C++ shop for interfaces to the O/S
or even to 3rd party libraries, I can safely bet that I'll find
naked arrays all over the place (even outside of your "interface
classes"). I'll grant you, that a few careful shops may be vigilant
about avoiding these issues, but it will _not_ be the _norm_.

There are at least two other problems that remain unsolved:

  1. There is no inherent overflow checking (not important in
     the pipe(2) case, but may be in other API calls).

  2. You now have to prove that your Class Posix is fault free
     before you put it on an aircraft or in a medical instrument.
     It has unsafe refs to naked arrays and does not have overflow
     or divide by zero checks.
     Proving safety is not as easy as it looks. The "I have extensively
     tested it" is not a convincing argument on its own. Additionally,
     C++ is notoriously difficult to read (translate: "code audit")

> There is only one possible 'Ada is better' argument: That
> something in the Ada libraries can not be provided cleanly by
> C++.

What makes this assertion true? You say it is, but don't provide any
evidence of this.  There are things I don't like about some of the
Ada packages, but I can say the same thing about C or C++. I don't
see this as a distinguishing feature for the purpose of this 
discussion. We were discussing safety inherent in the Ada language,
as compared to C++ (and C), not library features.

You know that it's easy to defend what you know and use. It's
harder to say "maybe there's something there that I should at 
least know more about."

I know this well, because I came from a position
similar to the one you're holding now. I finally bought a book,
installed GNAT, to find out what the "truth of the matter was".
I mean, I _really_ investigated -- ie. started writing code in it.
Lots of it!

I came away from the experience "converted", much to Ken Burtch's
surprise (he had for quite some time expounded the virtues of Ada,
which I confess, I sneered at).

One of my sneers was "C programmers don't need training wheels", 
which is how I rated "array bounds checks". Well, it turns out,
if these be "training wheels", then they are a good thing. The
reason is that the training wheels keep programmers from taking
corners more sharply than they they should ;-)

> As was observed earlier, C++ is far from uniform. The STL string
> classes do not bounds check, Microsoft's CString checks in debug
> mode, and the string class I am using as part of my utils lib
> checks unless explicitly switched into no-checking mode.
> 
> Chris

Chris, I really don't expect you to take my word for the strengths
of Ada. Nobody should. I didn't. However, I hope that there is
enough here, and by others, that you someday find the time to
install GNAT and get a book -- and actually use it for a while
in a recreational sense. ;-) I mean it.

I've tried to point out some practical issues to you. I've not
done the best possible job of this, but it helps if you keep
an open mind. Install GNAT.. try it. If you give it an honest
try and you still hate it, then at least you have informed 
reasons for it. But beware... you might just learn to 
like it ;-)

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg