Generic unknown RC/IO error while verifying initial ticket

[Ken Hornstein]

>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...

I'm sure there are counter-examples, but in my experience once an error
happens at a lower level, functions at (a) and (b) immediately return.
Sure, a stack might be nice, but I'm not convinced it's necessary
in most cases.

>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.

I'm not sure of the best solution here; I guess we could use Doug's
suggestion about matching error codes; that might solve most of these
cases.

--Ken