From a quick look, it looks like a struct-by-value problem.

i.e. uv_buf_init() returns a uv_buf_t by value, but you declare it to return a :pointer.

You'll need to find the layout of uv_buf_t and recreate it in FFI, then use it as the return value.

e.g.

if FFI::Platform.windows?

 # win32 has a different uv_buf_t layout to everything else.

  class UvBuf < FFI::Struct

    layout :len, :ulong, :base, :pointer

  end

else 

  class UvBuf < FFI::Struct

    layout :base, :pointer, :len, :size_t

  end

end

Then use UvBuf.by_value in place of uv_buf_t ... you can probably do that with typedef like you've done everything else, since uv seems to only use that struct by value (but you'll want to double check).

typedef UvBuf.by_value, :uv_buf_t

On Friday, April 6, 2012 7:50:55 AM UTC+10, avalanche123 wrote:

Hello,

I'm working on libuv ffi bindings for Ruby and have an issue I can't
understand

Libuv needs an allocated buffer it can write to, here is a gist of
code https://gist.github.com/2313277 that has my ruby module and usage
examples both in C and Ruby
The C example works fine, while ruby makes Libuv raise EINVAL. I've
used some basic debugging and figured out that the buffer len than
comes from Ruby is 140735085305696
instead of 128, as can be seen from shell outputs examples I've added
to the gist. I've also added relevant pieces of Libuv to the gist,
specifically uv_buf_init that is
responsible for creating uv_buf_t and part of libuv's uv__read that is
responsible for using it.

From my debugging it looks like a corrupted uv_buf_t memory comes back
from Ruby, making libuv believe beffer's len attribute is
140735085305696 bytes long.

I will appreciate any feedback as I've been struggling with this for a
while.

Best,
Bulat