This bug was never fixed in&nbsp;g_display_com_err_status().&nbsp; However, I believe all visible manifestations of it were fixed in 1.7.&nbsp; Details follow:<br />
<br />
Commit fcdd2de143971b0f020531479ad18f57874aef30 changed krb5_gss_display_status() to support extended error messages; in the process, it stopped using g_display_com_err_status().&nbsp; Commit&nbsp;abcfdaff756631d73f49103f679cafa7bc45f14e added the necessary cast to the error_message() call in the replacement code.<br />
<br />
g_display_com_err_status() is still used by the mechglue&#39;s&nbsp;g_display_com_err_status() when the minor code mapping does not contain a mech OID--meaning the code was generated by the mechglue, not by a mech.&nbsp; So, for this bug to remain visible, the mechglue would have to generate a com_err code within the negative range.&nbsp; System errors like ENOMEM are positive, so wouldn&#39;t manifest the bug.<br />
<br />
Since the mechglue sometimes delegates to functions in lib/gssapi/generic, codes in gssapi_err_generic.et are a concern, as that table is within the negative range.&nbsp; Currently, it looks like none of those codes are currently generated outside of a mech.<br />
<br />
I will add the cast as suggested, with a commit message note that it doesn&#39;t change anything in practice.