[libvirt] [PATCH] MacOS: Handle changes to xdrproc_t definition

With Mac OS X 10.9, xdrproc_t is no longer defined as: typedef bool_t (*xdrproc_t)(XDR *, ...); but instead as: typdef bool_t (*xdrproc_t)(XDR *, void *, unsigned int); For reference, Linux systems typically define it as: typedef bool_t (*xdrproc_t)(XDR *, void *, ...); The rationale explained in the header is that using a vararg is incorrect and has a potential to change the ABI slightly do to compiler optimizations taken and the undefined behavior. 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. --- src/rpc/virnetmessage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rpc/virnetmessage.c b/src/rpc/virnetmessage.c index d60366b..af07404 100644 --- a/src/rpc/virnetmessage.c +++ b/src/rpc/virnetmessage.c @@ -345,7 +345,7 @@ int virNetMessageEncodePayload(virNetMessagePtr msg, msg->bufferLength - msg->bufferOffset, XDR_ENCODE); /* Try to encode the payload. If the buffer is too small increase it. */ - while (!(*filter)(&xdr, data)) { + while (!(*filter)(&xdr, data, 0)) { unsigned int newlen = (msg->bufferLength - VIR_NET_MESSAGE_LEN_MAX) * 4; if (newlen > VIR_NET_MESSAGE_MAX) { @@ -402,7 +402,7 @@ int virNetMessageDecodePayload(virNetMessagePtr msg, xdrmem_create(&xdr, msg->buffer + msg->bufferOffset, msg->bufferLength - msg->bufferOffset, XDR_DECODE); - if (!(*filter)(&xdr, data)) { + if (!(*filter)(&xdr, data, 0)) { virReportError(VIR_ERR_RPC, "%s", _("Unable to decode message payload")); goto error; } -- 1.8.1.5

On Wed, Oct 30, 2013 at 11:28 AM, Doug Goldstein <cardoe@cardoe.com> wrote:
With Mac OS X 10.9, xdrproc_t is no longer defined as:
typedef bool_t (*xdrproc_t)(XDR *, ...);
but instead as:
typdef bool_t (*xdrproc_t)(XDR *, void *, unsigned int);
For reference, Linux systems typically define it as:
typedef bool_t (*xdrproc_t)(XDR *, void *, ...);
The rationale explained in the header is that using a vararg is incorrect and has a potential to change the ABI slightly do to compiler optimizations taken and the undefined behavior. 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. ---
This patch is another option to fix the issue seen on Mac OS X. The original is available here: https://www.redhat.com/archives/libvir-list/2013-October/msg01153.html -- Doug Goldstein

On 10/30/2013 10:28 AM, Doug Goldstein wrote:
With Mac OS X 10.9, xdrproc_t is no longer defined as:
typedef bool_t (*xdrproc_t)(XDR *, ...);
but instead as:
typdef bool_t (*xdrproc_t)(XDR *, void *, unsigned int);
For reference, Linux systems typically define it as:
typedef bool_t (*xdrproc_t)(XDR *, void *, ...);
The rationale explained in the header is that using a vararg is incorrect and has a potential to change the ABI slightly do to compiler optimizations taken and the undefined behavior. 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. --- src/rpc/virnetmessage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
ACK; passed my testing on Linux and Cygwin, and seems to be reasonable to avoid undefined C behavior where varargs ABI on some platforms could indeed give undesired results. Worth having in 1.1.4. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On Sat, Nov 2, 2013 at 11:55 AM, Eric Blake <eblake@redhat.com> wrote:
On 10/30/2013 10:28 AM, Doug Goldstein wrote:
With Mac OS X 10.9, xdrproc_t is no longer defined as:
typedef bool_t (*xdrproc_t)(XDR *, ...);
but instead as:
typdef bool_t (*xdrproc_t)(XDR *, void *, unsigned int);
For reference, Linux systems typically define it as:
typedef bool_t (*xdrproc_t)(XDR *, void *, ...);
The rationale explained in the header is that using a vararg is incorrect and has a potential to change the ABI slightly do to compiler optimizations taken and the undefined behavior. 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. --- src/rpc/virnetmessage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
ACK; passed my testing on Linux and Cygwin, and seems to be reasonable to avoid undefined C behavior where varargs ABI on some platforms could indeed give undesired results. Worth having in 1.1.4.
The patch works on FreeBSD 9.2 and Mac OS X 10.8.5. I prefer this simple version unless it breaks other platforms. ozaki-r
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Nov 1, 2013 at 9:55 PM, Eric Blake <eblake@redhat.com> wrote:
On 10/30/2013 10:28 AM, Doug Goldstein wrote:
With Mac OS X 10.9, xdrproc_t is no longer defined as:
typedef bool_t (*xdrproc_t)(XDR *, ...);
but instead as:
typdef bool_t (*xdrproc_t)(XDR *, void *, unsigned int);
For reference, Linux systems typically define it as:
typedef bool_t (*xdrproc_t)(XDR *, void *, ...);
The rationale explained in the header is that using a vararg is incorrect and has a potential to change the ABI slightly do to compiler optimizations taken and the undefined behavior. 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. --- src/rpc/virnetmessage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
ACK; passed my testing on Linux and Cygwin, and seems to be reasonable to avoid undefined C behavior where varargs ABI on some platforms could indeed give undesired results. Worth having in 1.1.4.
Thanks. Pushed. -- Doug Goldstein
participants (3)
-
Doug Goldstein
-
Eric Blake
-
Ryota Ozaki