Description of problem:
gss_display_status() returns wrong/unhelpful error messages for error codes that are more than
31 bits wide, if on a 64-bit platform.

Version-Release number of selected component (if applicable):
krb5-libs-1.6.2-9.fc8.x86_64

How reproducible:
100%

Steps to Reproduce:
kdestroy, then try to connect to a kerberos service.  Correct behavior is:

(gdb) bt
#0  error_message (code=-1765328189) at error_message.c:48
#1  0x00002aaaaaab420a in pg_krb5_init (errorMessage=0x643148, info=0x7ffffe08c1f0) at fe-auth.c:161
[ rest of stack is not interesting ]
(gdb) fin
Run till exit from #0  error_message (code=-1765328189) at error_message.c:48
0x00002aaaaaab420a in pg_krb5_init (errorMessage=0x643148, info=0x7ffffe08c1f0) at fe-auth.c:161
161                     printfPQExpBuffer(errorMessage,
Value returned is $1 = 0x387727cc13 "No credentials cache found"

But try to pass the same error through gssapi:

(gdb) bt
#0  error_message (code=2529639107) at error_message.c:48
#1  0x0000003877609edd in gssint_g_display_com_err_status (minor_status=0x7ffffe08c30c, status_value=2529639107, 
status_string=0x7ffffe08c2f0)
    at disp_com_err_status.c:58
#2  0x000000387760d307 in gss_display_status (minor_status=0x7ffffe08c30c, status_value=2529639107, status_type=2, 
req_mech_type=0x0, message_context=0x7ffffe08c308, 
    status_string=0x7ffffe08c2f0) at g_dsp_status.c:88
#3  0x00002aaaaaab43db in pg_GSS_error_int (mprefix=0x2aaaaaac5a00 "GSSAPI continuation error", msg=0x64b1fd "", 
msglen=163, stat=2529639107, type=2) at fe-auth.c:358
[ rest of stack not interesting ]
and you get a useless result:
(gdb) fin
Run till exit from #0  error_message (code=2529639107) at error_message.c:48
0x0000003877609edd in gssint_g_display_com_err_status (minor_status=0x7ffffe08c30c, status_value=2529639107, 
status_string=0x7ffffe08c2f0) at disp_com_err_status.c:58
58         if (! g_make_string_buffer(((status_value == 0)?no_error:
Value returned is $2 = 0x3877001cf0 "Unknown code krb5 195"

Actual results:
Unhelpful numeric dump of error code

Expected results:
The intended string for the message

Additional info:
The culprit is g_display_com_err_status(), wherein an OM_uint32 representation of the error code
is passed to error_message(), which expects a long.  On a 64-bit architecture the uint32 will be
padded with zeroes, whereas error_message is expecting a sign-extended value.

A minimum fix would be to cast status_value to signed int32 before letting it be widened to long.
However, I wonder whether there aren't some more fundamental issues here.  Presumably the intent
is that no error code will ever be too wide for 32 bits (else the code cannot work on 32-bit arches)
so maybe the code in error_messsage.c should be modified to deliberately mask off high order bits
to prevent confusion of this type in other places.

BTW, it seems like a pretty bad idea that there are two different versions of error_message.c in use
in the same set of libraries.  I am not quite sure who is responsible for pulling in libcom_err from
e2fsprogs, but that contains a version of error_message.c that is subtly different from the one in
the krb5 sources, and it scares the heck out of me that different parts of the program seem to be
calling different ones of the similarly-named routines.  That doesn't seem to be directly related
to the misbehavior I'm seeing, but maybe it is a factor in other bugs?  In any case it's confusing.