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

[Ted Dennison<dennison@telepath.com>]

In article <r1nuk9.2ua.ln@10.0.0.2>, Bart.Vanhauwaert@nowhere.be says...
>
>Ted Dennison <dennison@telepath.com> wrote:
>>>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". :-)
>
>I use it all the time (and love it)

I don't do C++ much, but it does happen. So I'm certianly putting it in my
bag-o-tricks (speed be damned).

>> o  In the Ada version, "i" would not be assignable within the loop. This 
>> allows the compiler to optimize things a lot more easily. 
>
>I am not really sure, why do you think that?

There is no (legal) possibility of aliasing, so it can *always* be kept in a
register. If the bounds are static (which they ususally are in an Ada "for" loop
that iterates through an array), it can even figure out at compile time exactly
how many loops there will be, and unroll (or not) accordingly. A really clever
optimizer might even be able to do sexy stuff like set the BPU to the right
value just before the loop is ready to fall out. All this can be done with C++
too, of course. But it would be a lot more work for the compiler to figure out
if it would be safe to do so.

>> Also, remember that all of us are not application programmers. Marin and I 
>> are systems programmers. I get quite suspicous of any *dynamic* data 
>I guess that's why you use Ada and I use C++? Best tool for the job
>and all that?

I suppose you could say that. But then, Ada doesn't exactly have problems with
dynamic data structures either. It just doesn't require them in a lot of places
where C does. There's still nothing stopping you from using them if you really
want to. You just have more options. However, I do have to admit that Ada is
really more of a "dream language" for systems programmers. For applications, it
drops down to meerly being a fair bit better. :-)  (Which isn't really enough
for a lot of people)

>However, predictability is achievable in C++ just as well as in C.
>For example all containers in the STL have an allocator as template
>argument. So if you need predictable memory allocation you can
>override the standard allocator and for example use memory from a
>pre-allocated pool.

I'll admit it is quite possible, in theory, to have nice predicitable allocators
and deallocaters. But for the most part, real-time programmers (and kernel
programmers, I'd imagine) avoid *any* dynamic allocations at all during runtime
like the plague. Even a good regular memory manager is going to take much longer
than a stack allocation and/or deallocation (which just involves moving the
stack pointer). To make matters worse, most OS'es (even RTOSes) *don't* come
with a good one. Thus all data typically gets allocated either at startup time,
or on the stack at runtime. Where I work, having a runtime dynamic memory op
discovered in your code is typically a one-way ticket to the doghouse. :-)

>> Systems software is pretty much what this thread is about. In particular, one
>Is it? I approached this thread from the application programming side.

Well, the topic is avoiding security problems like the Code Red worm. Worms like
this one use security holes in the OS (and near-OS systems software like email
servers and webservers). So yes, it is pretty much all about not using unsafe
languages to write Systems Software.

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