GnuTLS (libgrypt really) and Postfix

James A. Donald jamesd at echeque.com
Mon Feb 13 21:32:29 EST 2006


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

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

If bad code halts, it will not get incorporated into production code.
If bad code produces ignored error messages, it will get incorporated
into production code, including pacemakers etc.  Therefore libraries
intended for use with pacemakers, anti lock brakes, and the like,
should die on error (which in the case of antilock brakes forces a
hard reboot.

Code intended for pacemakers and the like should be error free.  If
you write libraries intended to continue after error, you are writing
on the assumption that the pacemaker code will be buggy, and we don't
really care, we are going to ship it anyway, bugs and all into other
people's chests.  People who write code for pacemakers that continues
on error should be shot.

Halt on error is a tool for achieving error free code.  Error free
code is in fact achievable for really crucial applications.  The more
crucial the application, the more reason to write code that halts on
error.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      Cau3evB8n2DnP2D8ej3FHKKnKnMeseK65pUDF346
      4FbXJRaadlYWOfMnkhNKfdLxDaKNb58AoLBUm8ox9

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



More information about the cryptography mailing list