[19974] in cryptography@c2.net mail archive
Re: GnuTLS (libgrypt really) and Postfix
daemon@ATHENA.MIT.EDU (James A. Donald)
Tue Feb 14 11:43:47 2006
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 14 Feb 2006 12:44:39 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: Dave Korn <davek_throwaway@hotmail.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <dsoi1o$ana$1@sea.gmane.org>
--
>>Libgcrypt tries to minimize these coding errors; for example there
>>are no error returns for the RNG - if one calls for 16 bytes of
>>random one can be sure that the buffer is filled with 16 bytes of
>>random. Now, if the environment is not okay and Libgcrypt can't
>>produce that random - what shall we do else than abort the process.
>>This way the errors will be detected before major harm might occur.
> I'm afraid I consider it instead a weakness in your API design
> that you
> have no way to indicate an error return from a function that may
> fail.
The correct mechanism is exception handling.
If caller has provided a mechanism to handle the failure, that
mechanism should catch the library generated exception. If the caller
has provided no such mechanism, his program should terminate
ungracefully.
Unfortunately, there is no very portable support for exception
handling in C. There is however support in C++, Corn, D, Delphi,
Objective-C, Java, Eiffel, Ocaml, Python, Common Lisp, SML, PHP and
all .NET CLS-compliant languages.
Absent exception handling, mission critical tasks should have no
exceptions, which is best accomplished by the die-on-error standard.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
Ywzx2XsxbvPNX+eeGZVUpnq16108eQo1eBvq8K1I
46HVM7avhGKHTF4Y1SqhFSUdIsTlbJvpXX43jkvQP
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
