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

[kaz@ashi.footprints.net (Kaz Kylheku)]

In article <3B6F5AAB.CF3A6ECA@home.com>, Warren W. Gay VE3WWG wrote:
>Kaz Kylheku wrote:
>> 
>> In article <3B6F312F.DA4E178E@home.com>, Warren W. Gay VE3WWG wrote:
>> >The STL is not used in all contexts (it's just not practical). If you call
>> >pipe(2), you will not be using a vector from the STL. You'll use a naked
>> >int[2] array. This is only one example.
>> 
>> Note that pipe() is an entry point into a POSIX operating system. Unless
>> you have POSIX Ada bindings, you are going to have to use the C interface
>> to call this thing at some point. The same goes for whatever programming
>> language you are using.
>
>Yes. So?

It means that you can't avoid conforming to the array representation
demanded by the system interface, no matter what language you are using,
unless you have native bindings that provide some alternate interface.
(And chances are that someone wrote those bindings as glue which uses
C routines).

So it's hardly a C++ issue. Note that pipe() is not even a standard C++
function. A program which calls pipe() is not a standard C++ program.

>> In C++, you have the advantage that you can use the C bindings directly.
>> It takes very little additional work to make C headers useable by a C++
>> implementation.
>
>This is a minor inconveniance for Ada, yes. But it is neither rocket
>science, nor a difficult thing to do. I do it in my sleep ;-)

You may have to do it in your sleep if you have to do it over and
over again for each platform. 

>> So you can make some class that encapsulates pipes, based directly on
>> the C interface.
>
>Yes, you _can_, but how often is that done?

All the time.

>The point I was making was there
>are a _lot_ of similar circumstances, where C++ would have to deal with
>this, and often the short cut is taken instead. Even when someone takes 
>the trouble to encapsulate the POSIX call, this means that _this_ 
>component is at least vulnerable to array bounds errors and is subject 
>to testing/debugging. This is the "weakest link!" ;-)

Same with any language that doesn't have a native POSIX call (or X Window
call, or Win32 call, or PalmOS call, ....)

If the language implementation doesn't give you a wrapper, you have
to hack one yourself.

>OTOH, if you define an array of two integers in Ada, even the "binding"
>has all array accesses checked, on this side of the POSIX call. Not so 
>in your C++ wrapper class.

But on the other hand, the C++ wrapper class will be highly
portable. Because the type ``int'' of your C++ compiler will correspond
to type ``int'' in the pipe() interface, and the call is checked
against the actual declaration.

Your Ada wrapper could pass in a pointer to two bytes instead of
two integers. Great, so you have checking on the Ada side, but
what ensures that the cross-language-boundary hack is correct?

Does Ada even give you a type that is guaranteed to be the same
as the type int of the predominant C compiler of the same platform
as the language implementation?

How do you *portably* declare, in Ada, a record type that 
is precisely equivalent to POSIX struct termios from <termios.h>?

You ahve several problems there. The exact contents of the
structure a implementation-specific. Moreover, the way the struct
members are padded is also platform-specific.

But you said you can do this stuff in your sleep! Pleasant dreams...

In C++, there essentially is no mixed language programming going on; you
call the C interfaces directly.  This is the reason for C++'s success on
the heels of C, being able to seamlessly integrate with interfaces that
have C bindings. To get that struct termios, you just include <termios.h>
in your C++ code, and, like, there it is!