On Thu, 29 Jun 2006, Derrick J Brashear wrote:
On Wed, 21 Jun 2006, Joe Buehler wrote:
Jeffrey Altman wrote:
ubik_Call() does provide a prototype because it is used as a
pseudo-vararg function.
afs_int32
ubik_Call(int (*aproc) (), struct ubik_client *aclient,
afs_int32 aflags, long p1, long p2, long p3, long p4,
long p5, long p6, long p7, long p8, long p9,
long p10, long p11, long p12, long p13, long p14,
long p15, long p16)
But what happens when the parameters that are being passed into
ubik_Call for later use by 'aproc' do not have the same size as
a 'long'? In that case the alignment of parameters on the stack
This is perilous for other reasons. On AIX, for example, my recollection
is that the first 8 parameters of a given type (float or int) are passed
in registers -- and floats and ints go into different registers. If there
are floats involved the above method of doing varargs may fail badly
because
the registers will get all confused.
I would say that the faster this sort of thing gets removed, the better --
it is based on ABI assumptions that are not valid for all machines.
I have a patch to kill it in testing now.
/afs/andrew.cmu.edu/usr/shadow/ubik-all.diff-2
Look at it, try it, etc, etc. It doesn't kill every use of ubik_Call, yet,
but it's good progress in that direction.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
