Assigning 64-bit errcode_t to 32-bit krb5_error_code

[Tomas Kuthan]

Hi,

(sorry for this being longish)

in krb5 sources error codes are mostly represented as two types:

typedef krb5_int32 krb5_error_code
typedef long errcode_t;

At some places values of the latter are assigned to variables of the 
former. It would make sense, if values assigned to errcode_t were 
guaranteed to fit in 32-bit integer (after all, errcode_t is 32-bit on 
32-bit architecture). In that case, the discrepancy would be merely a 
code purity issue.

But are there guaranties, that no function will ever return an error 
code that would overflow 32-bit integer?

I identified two areas in the code, where errcode_t value is assigned to 
krb5_error_code variable.

1) Extended error hook functions

Most of the hook functions call krb5_get_error_message, internally 
casting errcode_t to krb5_error_code and then back

extended_com_err_fn(..., errcode_t code, ...);
       krb5_get_error_message(..., krb5_error_code code);
             error_message(errcode_t code);
             k5_get_error(..., errcode_t code);

(Provided errcode_t is supposed to be long) this would be easily fixable.

2) Profile API

Profile API uses errcode_t internally and public functions are declared 
as returning long for error codes. At multiple places these longs get 
assigned to krb5_error_code variables.

e.g. src/lib/krb5/os/init_os_ctx.c:
374 static krb5_error_code
375 os_init_paths(krb5_context ctx, krb5_boolean kdc)
376 {
377    krb5_error_code    retval = 0;
...
387      retval = profile_init_flags((const_profile_filespec_t *) files,

And with profile plug-ins, the error code can origin in the plug-in, 
depriving the code from the control of the specific values. Unless there 
is some convention for the errcode_t values, the plug-in can return a 
64-bit value, where the lowest 4 bytes collide with some defined 
krb5_error_code value. In that case the 'lost of precision' in the 
assignment results in a wrong interpretation of the error code.

Is there anything (besides common sense) forbidding errcode_t values 
overflowing 32-bit integer?

Thanks,
Tomas