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

[Ted Dennison<dennison@telepath.com>]

In article <apesk9.env.ln@10.0.0.2>, Bart.Vanhauwaert@nowhere.be says...
>
>Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
>> And don't forget 'Range - very useful for "for" loops. And the same thing

>I am not really sure where this is fundamentally different from
>
>for (std::vector<int>::iterator i=v.begin(); i!=v.end(); ++i)

That's actually pretty close, and seems to have all the benifits Marin was
touting. Its a shame I've never seen it "in the wild". :-)

There are some differences, though:

o  In the Ada version, "i" would not be assignable within the loop. This allows
the compiler to optimize things a lot more easily. 
o  I'm not to sure how C++ compilers implement calls to the iterator's "++"
operator, but it looks like a function call to me (perhaps even a dispatching
one?). The Ada for loop is going to use whatever hardware incrementation method
is fastest (assuming it doesn't just unroll some or all of the loop). In a tight
loop, the speed difference could be significant.
o  In the Ada version, the range of "i" is much more likely (almost certian
actually) to be discernable at compile time. Again, this allows the compiler to
optimize things a lot more easily. It also means that there won't be extra code
(and time) used to figure out the bounds at runtime.

The first issue is due to the fact that C went for maximum "hackability", and
thus doesn't have a constrained loop form for optimizing compilers to work with.
The last two are due to C leaving type safety issues up to library writers,
rather than properly addressing them in the language itself.

>(Btw, as an application programmar, I get supicious whenever I see
>a fixed size array. It means some arbitrary limit (or arbitrary
>waste of resources) that some user eventually will stumble upon and
>of course complain)

Actually, in Ada a fixed sized array does not always mean that. You can go
figure out what the size needs to be (at startup time or runtime), and then
perform the array declaration.

Also, remember that all of us are not application programmers. Marin and I are
systems programmers. I get quite suspicous of any *dynamic* data structure, as
its liable to consume time that I don't have to spare. Sometimes the time
*variability* of dynamic memory operations can be a big problem too (eg: when
updating a display, your time between updates has to be *exact*, or things look
weird). There's a trade-off involved with choosing any particular data
structure, and you have to balance your requirements against those trade-offs.
Arbitrary limits may be annoying for your average GUI app, but device drivers
and OS kernels (especially RTOS's) are chock full of them, and for good reason. 

Systems software is pretty much what this thread is about. In particular, one
*shouldn't* have to balance safety and execution speed as much as C++ system
programmers have to. Given the choice, many systems programmers are naturally
going to decide that they just can't take the speed hit of using the safe
abtract classes (and some are just perverse and prefer not to either way). By
putting type safety in the language, rather than pushing it off into tacked-on
libraries, Ada allows safe code that can optimize much better and run much
faster than equivalently safe C++ code. With a little work, it can even be
faster than *unsafe* C++ code (due to issues like less aliasing and the
too-flexible for loop I mentioned above).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com