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

[Bart.Vanhauwaert@nowhere.be]

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)

> 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?

> 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.

This depends on the implementation of the STL of course. It certainly is
not a virtual function call. std::vector<What>::iterator is a either a
wrapper around an int or a pointer to What. In both cases it translates
to just pre-incrementing the pointer or the integer. Modern compilers
have no trouble optimizing this.

> 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.

True. Some compilers don't hoist the call to v.end(). If you feel
pathetic about it you can always do it by hand. I think for a non-trivial
loop it is lost in the noise. Better compilers optimize this completly
away of course.

> 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

I guess that's why you use Ada and I use C++? Best tool for the job
and all that?

> 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. 

Probably. I don't know anything about system programming.

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.

> Systems software is pretty much what this thread is about. In particular, one

Is it? I approached this thread from the application programming side.

cu bart

-- 
http://www.irule.be/bvh/