Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

Hi Pablo, correcting the type declaration in the ffiCall solved the problem, thanks! Cheers, Paulo On 10/30/2017 05:24 PM, teso...@gmail.com wrote: > Hi,  >  the problem is that the Zq function has the following signature: > > int zmq_msg_recv (zmq_msg_t *msg, void *socket, int flags); > > And

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

Hi, the problem is that the Zq function has the following signature: int zmq_msg_recv (zmq_msg_t *msg, void *socket, int flags); And in your ffiCall you are putting #long. You should use the correct size of integers, as the binary numbers need to extend the size when they are negatives.

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

Ah ok I know that one, just did not know it was named "two's complement" , looks to me normal error. I have seen this value many times in case of errors while debugging C code with GBP It returns error probably because of the reason I outlined in my previous reply. On Mon, Oct 30, 2017 at 3:51

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

"Two`s complement" is one possible way to represent signed integers in binary form (1). When the message apiZmqMsgRecv: message socket: socket withFlags: flagsis sent, as shown in my prior message, a function from libzmq, zmq_msg_recv (2) is called and the return value should be either the number

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

P.S.: some details of the setup follow. pharo --version: 5.0-201707201942  Thu Jul 20 20:40:54 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:

[Pharo-users] Return value of a FFI call to a external function is its 2`s complement

Dear uFFI experts, I am dealing with the port of the ZeroMQ code to Pharo 6 and found something unexpected to me, at least: Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags     ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage*