On Thu, Jun 23, 2005 at 12:37:28PM +1000, Matthew Palmer wrote: > [taken to the list, as Joe requested] > > On Wed, Jun 22, 2005 at 07:34:50AM +0100, Joe Orton wrote: > > You say "buried in a header file" as if you have some better description > > of the API somewhere which omits to mention this constraint. If you're > > I was using the best description possible: the source code.
That is the *worst* description possible. The interface and the implementation are two totally different things. You cannot infer what preconditions and postconditions the API requires and provides from reading the implementation. That is what the header file does. The implementation is irrelevant, it may change completely in future releases. > ne_openssl.c:479. By trawling down into that function, and looking at > dup_client_cert (which is a private function) there we see a quick comment > about encrypted certs. But the public function I used does not make mention > of the need for decryptedness. The only place dup_client_cert is used is by ne_ssl_set_clicert. The description of that function is, again, absolutely 100% clear about this: /* Use the given client certificate for the session. The client cert * MUST be in the decrypted state, otherwise behaviour is undefined. */ void ne_ssl_set_clicert(ne_session *sess, const ne_ssl_client_cert *clicert); what am I missing? > API docs or not, though, programmers are going to make stupid mistakes, like > not decrypting their certificates. Segfaulting is not an appropriate > response to a problem which is so easily checked at runtime by neon. Undefined behaviour is undefined behaviour is undefined behaviour. The library is supposed to implement the API, nothing less and nothing more. > > not reading the header file (or ref docs) to find out how the API is > > The ref docs[1] are out of date. They don't even mention any clicert > functions. Right, the header file is authoritative. joe _______________________________________________ neon mailing list [email protected] http://mailman.webdav.org/mailman/listinfo/neon
