GnuTLS (libgrypt really) and Postfix

[John Denker]

On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
 >>     Yet, I agree it is poor design to [exit] in a library.

I agree, it is a poor design.


Werner Koch retorted:
> 
> I disagree strongly here.  Any code which detects an impossible state
> or an error clearly due to a programming error by the caller should
> die as soon as possible.  

That is a remarkably unprofessional suggestion.  I hope the people
who write software for autopilots, pacemakers, antilock brakes,
etc. do not follow this suggestion.

First of all, "impossible" is the wrong word.  If the condition
were truly impossible, it would absolutely never happen, and
there would be no need even to check for it.  Instead, it would
be better to speak of conditions that "should" never happen, or
more precisely, conditions that are outside the range of what
the code can handle.

As an introductory example, let "you" be the computer.  Imagine you
are minding your own business, about 2500 feet above the surface
of the moon.  You detect a condition that "should" never happen;
namely, there is not enough time to execute the required tasks
in real time, i.e. the next clock tick occurs before all the
previous tick's tasks are finished.  What do you do, exit?  If
you exit, you kill everybody on board.  That seems suboptimal
IMHO.  Maybe it would be wiser to issue an alarm ("1201") and
keep going, leaving low-priority tasks unfinished, while still
dealing with high-priority tasks on schedule.

   Long, long afterward it is discovered that somebody inadvertently
   left the docking radar turned on during the descent.  That
   "should" have never happened.  But it did happen.  Deal with it.

There are other stories like this, including funny (?) stories of
what happens if exceptions are not handled so well.

More generally:  library routines should never exit.  They almost
by definition do not have a high-level view of what is going on,
whereas the decision to exit is quite a high-level decision.  It
is permissible for library routines to throw an exception;  then
the higher-level code can catch the exception if it wishes to.
If the language doesn't handle exceptions well, it is permissible
to return an exit status ("1201") that gets passed up through the
layers of callers.

   Nitpickers note:  I can imagine a situation where the stack is so
   messed up that you can't thrown an exception or even return from
   calls.  (Actually I don't need to imagine it;  I've dealt with
   such situations.)  However,
    a) That is not even remotely similar to the situation that led
     to the remarks quoted above, and
    b) Even then there are high-level things that you can do to
     recover from the situation, and there is no excuse for
     arrogant unprofessional low-level routines usurping high-level
     functions by halting or exiting.

http://www1.istockphoto.com/file_thumbview_approve/270860/2/istockphoto_270860_background_removed_no_exit_sign.jpg

=====================

Tangential philosophical note:  I have a saying that
   "All exceptions are caught and handled;  it's just a
   question of where and how."

Extreme examples:
  -- Under unix, exit() is caught by the atexit() routines.
  -- Similarly, _exit() is caught by the parent process.
  -- A hardware halt is caught by the operator and handled
   by pushing the reset button.

In many situations, these extreme handlers are far too drastic and
inflexible, so you should arrange for less-extreme handlers.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com