[OpenAFS-devel] Re: patches for afs-krb5 (fix 64-bit bug, etc)

[Ken Hornstein]

>1. res_search can be a macro (i.e. on recent linux glibc, AMD64). I just
>copied the workaround for this out of the openafs source tree:
>
>	http://www-personal.engin.umich.edu/~wingc/aklog/patches/1-res_search.patch

Hm, since we don't ever call res_search, I'm not even sure we need this
test; might as well delete it alltogether.

>2. Some systems use libcom_err as a shared library; in this case,
>add_to_error_table() is already provided and we don't need to build it
>ourselves:
>
>	http://www-personal.engin.umich.edu/~wingc/aklog/patches/2-com_err.patch

Sigh, the whole com_err mess is neverending.

>3. It looks like MIT krb5-1.3 no longer includes a separate libkrb524, but
>instead moved the krb524 functions into libkrb5. Handle this:
>
>	http://www-personal.engin.umich.edu/~wingc/aklog/patches/3-krb524.patch

At least this makes dealing with krb524 easier.

>5. And finally, here's an actual bug. krb5_build_principal() is a varargs
>function that expects a list of string pointers, terminated by a final
>NULL. The original aklog code used '0' instead, which is passed as an int
>and not automatically promoted to a pointer (as would be the case if it
>was specified for a fixed argument). On a 64-bit machine, this results in
>pushing a 32-bit value onto the stack instead of the expected 64-bit
>pointer. So krb5_build_principal() never finds the terminating null and
>starts following invalid pointers.

Turns out you learn something new every day.  However ... I'm not sure
this is necessarily the correct approach.  From what I've read, NULL is
not guaranteed to be ((void *) 0) (or something similar).  I think
the best solution is to have an explicit cast in that statement.

--Ken