>>
>> I don't think I'm explaining this very well, so here's an example:
>>
>> In rx_kcommon.c, there are four references to osi_Panic (lines 264,
>> 285, 977, & 1304) with varying numbers of arguments. Because
>> osi_Panic on aix/irix is implemented with a mandatory 4 arguments,
>> these lines raise errors when compiling.
>
> Yes, and osi_Panic on aix/irix taking 4 arguments is wrong, it is a bug
> (as far as I can tell, unless someone claims otherwise). Change it to
> take an unspecified number of arguments.
>
> That is, change the declaration in rx_prototypes.h to read
>
> extern void osi_Panic();
Yes, done -- Derrick's submitted a patch which removes the prototype on irix.
That's not the issue. The prototype is a red herring. That's not what's
causing the problems in rx_kcommon mentioned above, where there are references
to osi_Panic with one or two args instead of always four. Because these
references occur in places which are also compiled on aix and irix, they should
fail to compile. Indeed, they do on irix. I don't see how they don't on aix,
but I'm not really concerned about that. I just want to find the best way
forward for all platforms. That's why I'm asking here. I'm happy to do
something like this for all rx_kcommon osi_Panic()s:
#if defined(AFS_AIX_ENV) || defined(AFS_SGI_ENV)
osi_Panic("osi_AssertFailK: error in osi_utoa()\n",
NULL, (void *)NULL, (void *)NULL);
#else
osi_Panic("osi_AssertFailK: error in osi_utoa()\n");
#endif
which does compile. I just thought that perhaps there was a more general
solution, like a change to osi_Panic itself. For instance, I believe irix does
support stdarg in the kernel. It doesn't have v*printf, but it has a function
that could be used in its stead (cmn_err(), see link below) which does take va.
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/catD/cmn_err.z
-Chaz
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your
desktop!
Check it out at http://www.inbox.com/marineaquarium
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
