Jim Rees wrote:
We don't need to pin down why the code isn't working. It's wrong to reference an arg that hasn't been passed[1]. How it fails is not important.
Yes and no. Are there other similiar errors in other calls to ubik routines? It looks like all the ubik code was setup to handle p1-p16. So why does authclient.c define its own kawrap_ubik_CallIter with only p1-p8, and then call ubik_CallIter with only p1-p8? (It even has a comment that some are spares. It could at least add p9-p16 as dummy? (Note it also use void * rather then long. This could come back to bit something too.)
Looks like the only other places ubik_callIter is called are in kauth/admin_tools.c and libadmin/kas/afs_kasAdmin.c The both use only p1-p8.
I suggest these these be expanded to pass 0 as p9-p16 in afs_kasAdmin.c and authclient.c at least for now.
Moving the needlock arg earlier just paints over this one symptom. It does not fix the problem.
I agree it just paint ovet the problem.
I expect the best solution here is to switch to varargs. Another possible solution would be to use an argument vector, but that means changing the function prototype.
The problem is there is no function protptype in one module, and the other two have:
extern int ubik_CallIter(); afs_uint32 ubik_CallIter();
[1] K&R sec 4.3. "It is generally safe to deal with a variable number of arguments if the called function doesn't use an argument which was not actually supplied."
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
