>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 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
