Thanks for the quick response Jeremy.<span></span><br><br>On Thursday, October 23, 2014, Jeremy Yallop <<a href="mailto:yallop@gmail.com">yallop@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 October 2014 11:48, Trevor Smith <<a href="javascript:;" onclick="_e(event, 'cvml', 'trevorsummerssmith@gmail.com')">trevorsummerssmith@gmail.com</a>> wrote:<br>
> I tried this out this morning. However I am seeing strange behavior with the<br>
> memory addresses. In native code, whenever I pass a pointer through the<br>
> accessor I receive a different address than the original address -- however,<br>
> in valgrind the addresses are the same.<br>
><br>
> Relevant code:<br>
> git clone git@github.com:trevorsummerssmith/ocaml-libuv.git && cd<br>
> ocaml-libuv && git checkout origin/test-lifecycle && make tests<br>
><br>
> I see, eg:<br>
><br>
> loop: 0x109d76800<br>
> Handle: 0x9d76800<br>
> Handle: 0x9d76800<br>
> F.<br>
> ==============================================================================<br>
> Failure: handle suite:0:accessors<br>
><br>
> The loop address always starts with '10'. However in valgrind the addresses<br>
> are the same.<br>
><br>
> The c accessors are in lib_gen/lib_accessors.c, the test is in<br>
> test/<a href="http://test_handle.ml" target="_blank">test_handle.ml</a><br>
<br>
The code generated by ctypes doesn't have declarations  for your<br>
accessor functions in scope, so the C compiler helpfully assumes that<br>
the functions return (32-bit) ints rather than (64-bit) pointers,<br>
leading to garbage in the upper bits.  You should be able to fix the<br>
problem by outputting suitable declarations (perhaps by including a<br>
header) in <a href="http://libuv_bindgen.ml" target="_blank">libuv_bindgen.ml</a>.<br>
</blockquote>