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

[Bart.Vanhauwaert@nowhere.be]

Ted Dennison <dennison@telepath.com> wrote:
> Can it? In Ada at least, I understand that potentially dynamic-dispatching
> operations are really tough to inline. I suppose there could be something I
> don't know about C++ that gets rid of that issue. Is there?

In C++ the programmer explicitly tells the compiler if a member
function needs to be dynamically-dispatchable. (virtual). Overloaded
operators however are never dynamically-dispatchable.

And anyway, even if we didn't use the pre-increment operator but
our own do_incr() member which we did make virtual, dynamic-
dispatch wouldn't be applicable since the control variable
is not a pointer to an object or a reference but an object. In
that case runtime type = compiletime type and hence the compiler
knows which member to call.

> Well, that's easy to *say*. But if your compiler can't inline dispatching calls,
> and "++" is a dispatching call, then it won't get inlined, and you will have
> procedure call overhead for every increment. This isn't an issue at all for Ada

Well, it is easy to *say* if you know how it works. There is no
dynamic dispatch here and thus inlining is perfectly possible.

> "for" loops, because the incrementing is *implicit*. Well...to be truthful,
> you'd have the same issue with Ada if you used some abstract tagged private type
> in a "while" loop instead, which would be a direct translation of what you've
> done in C++. But in Ada you don't need to do that just to get type safety. The
> base types already have it (if you don't disable it).

Exactly for cases as this, you can
put implementations of potentially inlineable members in the headers.
That way the compiler has seen all information it needs to easily
decide when (and how) to inline.

> Quite true. The difference is that its much *easier* for an Ada compiler to do
> this, becuse far more of the nessecary information is available to the optimizer

There is no question that writing a good optimizing C++ compiler is a
VERY difficult task. Some come close but none are optimal. However,
this is one of the easier cases to optimize. You are not doing your
case any good by insisting that this might be a problem in the
real world. There are a lot of things which are a lot harder and
where a critique for C++ as a difficult to optimize language is
much more appropriate.

> at compile time. For instance, its tough to fully unroll a loop, if you don't

Given modern CPU's it is actually a loss to agressively unroll
or inline. ichache pressure and such does that to you. In a lot
of cases a missed cache hit is much more costly than a simple,
easy to branch predict call.

cu bart

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