Re: terminate applications

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:vi0gf8rnbu9b09@corp.supernews.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.

But dangerous for whom?  RAVENSCAR defines a number of Ada
features that they consider "unsafe", yet these features are
not soon to be removed from the "standard".

You must look at the application first. The OP has an "application"
for this feature, and I think it is presumptuous for us to say
that it is too dangerous to be used.

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

Let me ask a hypothetical question: which car would you prefer?

  1. Your year 2030 minivan says to you "I will not start because the
     hatch sensor indicates that it is not fully closed."  "Please
     correct the problem or get it repaired and try again. Have
     a nice day!"

or

  2. Your year 2030 minivan says "I will not start because the hatch
     sensor indicates that it is not fully closed. If you have
     checked the hatch, and it appears OK, then enter code XYZZY
     and then I will proceed anyway."

Which would you choose?  Microsoft will offer the #1 firmware.


For me, it better be #2, because I want to be in control! Not the
so and so manufacturer!

I think this API feature is about control. It has many times been
conceded that this is not the correct thing to do. But there are
_practical_ needs for this, if not for anything else, but for
testing.

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

Ah, but exit() is only one C choice. The function _exit() is _also_
callable by the C programmer. Again, it is acknowledged that there
are good reasons not to use this, but the C programmer DOES have
the CHOICE to do so when it is required.

Give the programmer a choice. Document it as dangerous or
unsupported, but give the programmer the choice. Management can
dictate it out of a project if it needs to.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg