Generic unknown RC/IO error while verifying initial ticket
Ken Hornstein
kenh at cmf.nrl.navy.mil
Wed Dec 1 12:45:10 EST 2004
> >> 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
More information about the Kerberos
mailing list