k5_bcmp acts similarly to the deprecated Unix bcmp() function,
returning zero if two memory regions are equal and nonzero if they are
not.  It is implemented such that it should take the same amount of
time regardless of how many bytes are equal within the memory regions.

Avoid using "magic numbers" for better maintainability.

This was previously not an issue because nothing outside of
libkrb5support used them.

Document that k5_json_object_set can be used to overwrite an existing
key, and make it possible to remove a key by setting it to NULL.

The internal UTF-8 to UCS-2 conversion functions did not properly
respect their length arguments, instead assuming that the input string
is terminated with a zero bytes.  As a result,
krb5int_arcfour_string_to_key could fail on unterminated inputs.  Fix
the underlying support functions to read their inputs only up to the
specified length.

ticket: 7643 (new)

Provide default values in pre.in for PROG_LIBPATH, PROG_RPATH,
SHLIB_DIRS, SHLIB_RDIRS, and STOBJLISTS so that they don't have to be
specified in the common case.  Rename KRB5_RUN_ENV and KRB5_RUN_VARS
to RUN_SETUP (already the most commonly used name) and RUN_VARS.  Make
sure to use DEFINES for local defines (not DEFS).  Remove some other
unnecessary makefile content.

Locking and unlocking a non-recursive mutex is a simple memory
operation and should not fail on any reasonable platform with correct
usage.  A pthread mutex can return EDEADLK on lock or EPERM on unlock,
or EINVAL if the mutex is uninitialized, but all of these conditions
would reflect serious bugs in the calling code.

Change the k5_mutex_lock and k5_mutex_unlock wrappers to return void
and adjust all call sites.  Propagate this change through
k5_cc_mutex_lock and k5_cc_mutex_unlock as well.

Reported by Arlene Berry.

ticket: 7629

By a strict reading of the C standard, memcpy and memcmp have
undefined behavior if their pointer arguments aren't valid object
pointers, even if the length argument is 0.  Compilers are becoming
more aggressive about breaking code with undefined behavior, so we
should try to avoid it when possible.

In a krb5_data object, we frequently use NULL as the data value when
the length is 0.  Accordingly, we should avoid copying from or
comparing the data field of a length-0 krb5_data object.  Add checks
to our wrapper functions (like data_eq and k5_memdup) and to code
which works with possibly-empty krb5_data objects.  In a few places,
use wrapper functions to simplify the code rather than adding checks.

Get rid of unnecessary null checks before freeing values in
libkrb5support's plugin code.