[22960] in Kerberos
Re: Generic unknown RC/IO error while verifying initial ticket
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Wed Dec 1 12:46:07 2004
Message-Id: <200412011745.iB1HjAvm009463@ginger.cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <878y8iglm6.fsf@luminous.mit.edu>
Date: Wed, 01 Dec 2004 12:45:10 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Errors-To: kerberos-bounces@mit.edu
> >> Would you be interested in helping design a way to do this?
> >> Heimdal allows an error string to be stored inside a context
> >> and retrieved later. That gives you enough flexibility to
> >> store the file name etc. The complexity is that we would need
> >> to go through the code and find every place where we have an
> >> error return and at least clear that string so the error
> >> returned always corresponded to the string if it was set.
>
> Douglas> Tag the string with the error code too, so only clear it
> Douglas> if the error code to be reported to the user does not
> Douglas> match the error with the message.
>
>Yeah, that works. It means the user has to pass in both a context and
>an error code to get the (possibly enhanced) error string.
>
>I think having to pass in an eventually unnecessary error code is an
>acceptable price to pay for reasonable error reporting from krb5.
So, I'm trying to understand how this would work from an API perspective.
Would this simply be hooked into com_err and friends? I ask because I
thought there was a goal of being able to use a third-party supplied
com_err library with MIT Kerberos (but maybe I'm thinking about
OpenAFS). I don't particularly care about that goal myself, but I
wanted to know if the intention was to continue to use the com_err API
or provide a new library function? I have a lot of code which uses
com_err, and it sure would suck to have to change it.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos