On Thu, Nov 30, 2023 at 09:30:28AM -0500, Andrea Bolognani wrote:
On Thu, Nov 30, 2023 at 02:07:55PM +0000, Daniel P. Berrangé wrote:
+++ b/scripts/rpcgen/tests/test_demo.c @@ -3,6 +3,10 @@ #include <rpc/xdr.h> #include <stdbool.h>
+#ifdef __APPLE__ +# define xdr_uint64_t xdr_u_int64_t +#endif
For the long run, I think it would make more sense to have this workaround as part of the generator's output, so that using VIR_TEST_REGENERATE_OUTPUT will produce the same results regardless of whether it's run on Linux or macOS. It would also avoid the need to add a similar workaround somewhere in the library code the day we start needing uint64_t anywhere in our RPC protocol.
As a short-term solution, it's fine :)
Never mind, this very obviously doesn't pass muster: E AssertionError: assert '\nvoid xdr_T...rn TRUE;\n}\n' == '\nvoid xdr_T...rn TRUE;\n}\n' E Skipping 9072 identical leading characters in diff, use -v to show E - if (!xdr_uint64_t(xdrs, &objp->suh)) E + if (!xdr_u_int64_t(xdrs, &objp->suh)) E ? + E return FALSE; E if (!xdr_bool(xdrs, &objp->sb)) E return FALSE;... E E ...Full output truncated (90 lines hidden), use '-vv' to show My test setup was a bit wonky so I initially failed to catch it. Apologies for the noise. The approach I suggested above would work, I think, but from a very quick look at the generator I wasn't able to figure out how it decides whether to use xdr_uint64_t or xdr_u_int64_t in the output. -- Andrea Bolognani / Red Hat / Virtualization