error info handling in MIT krb5 code

Jeffrey Hutzelman jhutz at
Mon Mar 27 19:51:49 EST 2006

On Friday, March 17, 2006 02:46:13 PM -0500 Ken Raeburn <raeburn at> 

> On Mar 17, 2006, at 14:13, Ken Hornstein wrote:
>> I'm curious ... how would this look in application code?  Are
>> applications intended to call com_err which will use
>> krb5_get_error_string(), or are applications supposed to call
>> krb5_get_error_string() directly?
> Since there'd be a krb5_context involved, krb5_get_error would have
> to be called directly from the application, in general.  Though since
> com_err provides a hook for intercepting calls, an application that
> used only one krb5_context and stuffed it in a global variable
> somewhere could set the hook function to something that calls
> krb5_get_error.  (They wouldn't be able to intercept error_message,
> which would be used in these new routines; just com_err() calls.)

Actually, you could do one better than that.  If you use one krb5_context 
per thread, you can store a pointer to it in thread-specific data, and your 
hook function can use that.

But in general, I would expect com_err itself not to change, and 
applications to use the krb5 error interfaces directly when it knows it is 
using the Kerberos API.  Among other things, a com_err code that happens to 
be in the krb5 space might not have been generated by the same thread or 
the most recent call or even the same Kerberos library (think network 

-- Jeff

More information about the krbdev mailing list