Re: [PATCH] MacOS: Handle changes to args in xdrproc_t

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 30, 2013 at 1:30 PM, Doug Goldstein <cardoe@xxxxxxxxxx> wrote:
> On Tue, Oct 29, 2013 at 6:28 PM, Eric Blake <eblake@xxxxxxxxxx> wrote:
>> On 10/28/2013 12:05 PM, Doug Goldstein wrote:
>>> With Mac OS X 10.9, xdrproc_t is no longer defined as:
>>>
>>> typedef bool_t (*xdrproc_t) (XDR *, void *, ...);
>>>
>>> but instead as
>>>
>>> typedef bool-t (*xdrproc_t) (XDR *, void *, unsigned int);
>>>
>>> The rationale explained in the header is that using a vararg is
>>> incorrect and has a potential to change the ABI slightly. They decided
>>> to specify the exact number of parameters and for compatibility with old
>>> code decided to make the signature require 3 arguments. The third
>>> argument is ignored for cases that its not used and its recommended to
>>> supply a 0.
>>> ---
>>>  configure.ac            | 41 +++++++++++++++++++++++++++++++++++++++++
>>>  src/rpc/virnetmessage.c | 10 ++++++++--
>>>  2 files changed, 49 insertions(+), 2 deletions(-)
>>>
>>
>> I'd like some feedback from someone else who can actually test this on
>> MacOS, as well as FreeBSD, but it does seem reasonable to get in 1.1.4.
>
> Gave this a change a whirl on FreeBSD 9.2 and it was fine. But
> obviously more testing is better.

I tested this patch on FreeBSD 9.2, Mac OS X 0.7.4 and 10.8.5.
It worked on all of them.

  ozaki-r

>
>>> +      AC_DEFINE_UNQUOTED([XDRPROC_T_ARG_COUNT], [$lv_cv_xdrproc_t_args],
>>> +                         [number of arguments that xdrproc_t func ptr takes])
>>
>> Seems reasonable; but I'm a bit worried about accepting args=2 in the
>> cases where we actually needed the varargs to pass 3.  It may be safer
>> to pass 3 always, unless we have empirical evidence that uclibc will
>> fail to compile if we don't limit to exactly 2 (and not just a thread
>> archives where they were contemplating forcing just 2, but where I don't
>> know if the thread was actually applied as a patch).
>
> fwiw, it appears that uclibc master [1] has not gone that route so I'm
> not sure what became of that thread. Hard coding our implementation to
> always pass 3 arguments was my other approach that I had mentioned on
> IRC but I wasn't sure about any negative repercussions on other
> platforms.
>
> [1] http://git.uclibc.org/uClibc/tree/include/rpc/xdr.h#n149
>
> --
> Doug Goldstein
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]