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

[Ted Dennison<dennison@telepath.com>]

In article <hPKb7.26397$B37.531734@news1.rdc1.bc.home.com>, Kaz Kylheku says...
>
>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?

Most of this stuff is not a *hack*. Its in the Ada standard. The Ada standard
validation process ensures that the standards are upheld.

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

Yes it does: Interfaces.C.Int. It also gives you the capability of creating an
integer type that is guaranteed to be the same number of bits reguardless of the
platform, which C and C++ do not give you. 

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

The version I have from cygwin just contains an include for sys/termios.h and 6
routine declarations. A portable binding to the routines would be trivial using
the types in Interfaces.C (assuming the ".h" file itself is really portable,
which with C is generally a bad assumption).

The termios struct itself (in sys/termios.h) uses unsigned shorts, chars, and
unsigned chars. All of those types are avilable for portable use in
Interfaces.C. Thus making a binding that matches this *portably* would be
trivial. It can be (and in some cases has been) generated by a translator
program.

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

The second problem is a non-issue. If you apply "pragma Convention (C, foo);" to
the declaration, its supposed to align the record the way C would align it.

However, you are right that Ada can't guard against the possiblity that termios
on another platform may not be the same struct. Ada that depends on C is indeed
not portable when the C itself isn't portable (which unfortunately is just about
always). If that's your point, I'd have to agree. That's why it pays to remove
yourself from the C as far as possible. :-)

However, if the differences in .h files don't affect the users much (which it
doesn't, if you use the routines and macros), then C-forced changes in the
innards of the Ada bindings won't affect the binding users much either (assuming
they stuck to the provided routines, which you can *force* in Ada by making the
record fields private).

Think of Ada "bindings" as just the Ada equivalent of the C .h files you're
accustomed to using for the same services. Most C compilers come with all the
system .h file "bindings", and most Ada compilers come with all the system
package "bindings". If the interface provided by C is reasonably portable, the
Ada interface will be at least as portable. If the *implementation* provided by
C is portable, the implementation provided by Ada can be made portable too. The
system services themselves will work just as well either way. System services
are machine code at this point, and won't ever know the difference. The only
real difference is that you aren't stuck using C. :-)

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