Generic unknown RC/IO error while verifying initial ticket

[Ezra Peisach]

Hmm - without much code changes from the external API....

a) There could be a new function krb5_get_extended_error_text - or
something like that - to retreive the extended message... 

b) There would be an equivalent function to create an extended error
message. (thread specific context?) 

c) When the error table is initialized - install a com_err_proc that
will query the extended error and format it nicely. If an extended error
is not present - don't display.

This would not require any "user" level changes then.

But - here are the issues:

If I have a call chain of a->b->c.  If (c) registers an error - sets the
extended error code and returns to (b) - should (b) then be able to
register it's own complaint and extended error - or would that mask
(c)'s message.  We sort of need a stack... Upon entry to a high level
kerberos function - the error stack would then need to be
cleared at critical juncture... Otherwise - the call stack is sort of
meaningless - as errors will be added  - but never cleared...

For instance - before the (a)->(b)->(c) - the client code invoked (d) -
which returned an error (say credential not found)... The client code
was smart - and expected such an error - and then did the a-b-c route
when it encountered the next error - and calls com_err. Reporting the
error stack would then display (d) - which is not relevant.

So - we would need to be careful... A stack will give the most details -
and prevent masking the underlying problems - with a cost in that all
entry paths need to be understood.  The tradeoff of a single extended
error has the risk of masking the error with a higher level message.

Ezra