Re: terminate applications

["Randy Brukardt" <randy@rrsoftware.com>]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F1FC849.8070202@noplace.com...
> If most OS's provide a given feature, there ought to be a way for an Ada
> program to utilize that feature in a standard way. Worrying about the
> fact that some OS provided feature might not fit in with Ada's desired
> safety and security is what is going to guarantee that programmers are
> going to do end-runs around Ada to use the C/C++ library that *will*
> give them the feature - and eventually decide that its too much of a
> nuisance to be programming in both Ada and C and revert to C.

I agree that common operations from the OS ought to be supported in a
standard way. But I disagree that that includes dangerous operations.

Don't you think that if the standard Ada library provided a safe Halt
routine, people would use that, and 98% of the time, it would be perfectly
adaquate? I cannot remember a case (either from us or from our users) where
someone said that System.Util.Halt was too slow or hung.

Similarly, if Ada provided "safe" libraries of OS operations, don't you
think people would use them? Do you really think that people would say that
such-and-such an operation is safe, so I won't use it?

Why should we go on propagating the mistakes of our forefathers? The
functionality is the important point, not the exact form or details. If you
don't believe that - if you believe that Ada can't be object-oriented
because it doesn't declare "class"es, for instance - then you SHOULD be
using C++. Ada has nothing to offer you then.

We should stick with "safe", well-defined operations in the standard Ada
library. After all, people will use those first. If they absolutely have to
use an unsafe operation, fine, but they'll have to do it by a direct
interface to the OS (making the OS dependence clear).

(For what's its worth, the C Exit is a safe exit -- for C. It does lots of
finalization activities before it actually exits. Why should Ada be
different in that regard?)

                              Randy.