[19970] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: GnuTLS (libgrypt really) and Postfix

daemon@ATHENA.MIT.EDU (Werner Koch)
Tue Feb 14 11:40:59 2006

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: Werner Koch <wk@gnupg.org>
To: John Denker <jsd@av8n.com>
Cc: David Wagner <daw@cs.berkeley.edu>, cryptography@metzdowd.com
Date: Mon, 13 Feb 2006 20:09:09 +0100
In-Reply-To: <43F03E3E.2050400@av8n.com> (John Denker's message of "Mon, 13
	Feb 2006 03:07:26 -0500")

On Mon, 13 Feb 2006 03:07:26 -0500, John Denker said:

> That might lead to an argument in favor of exceptions instead of error
> codes, along the following lines:
>  -- Naive code doesn't catch the exception.  However (unlike returned
>   error codes) this does not cause the exception to be lost.
>  -- The exception percolates up the call-tree until it is caught by
>   some non-naive code (if any).
>  -- If all the code is naive, then the uncaught exception terminates
>   the process ... to the delight of the "exit on error" faction.
>   However (!!!) unlike a plain old exit, throwing an exception leaves
>   the door open for non-naive code to implement a nuanced response to
>   the exceptional condition.

Actually the plain C similar thing is done for an internal error:
SIGABRT is raised and the top level code (or in theory any layer in
between) may catch it and try to continue.  Okay, this won't work in
practise because signal handling between independent developed code
(libraries) is guaranteed not to work correctly. 

And yes, we need to discuss whether whether a failed open should abort
or exit.  As of now it does an exit and not an abort() but I won't
insist on this.

> Again, enough false dichotomies already!  Just because error codes are
> open to abuse doesn't mean exiting is the correct thing to do.

For Libgcrypt's usage patterns I am still convinced that it is the
right decision.


Salam-Shalom,

   Werner





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

home help back first fref pref prev next nref lref last post