Joe Buehler wrote: > 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.
We are well aware of the seriousness of the situation. There are 374 calls to ubik_Call() in the code and that is a lot of surgery to perform. Jim Rees wrote: > I assume these are leftover from the days when not all platforms had > varargs, and can be changed now to use varargs. Unfortunately this is > easier said than done. Using varargs is not a desirable solution because it does not provide for any additional compile time type safety. There are two proposals on the table at the moment. One involves redefining ubik_Call() to take a procedure specific data structure containing the procedure's parameters. The other involves getting rid of ubik_Call() entirely by incorporating its functionality into the generated RPC client stubs. Derrick Brashear is evaluating the feasibility of the two proposals. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
