"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 of bytes in the received message or -1, in case of an error. Well, I was expecting to get a -1 as return value when calling the function in non-blocking mode, but it returns 0xFFFFFFFF, which happens to be the 2's complement representation of -1. At least the old code for libZMQ was not expecting that. Cheers, Paulo (1) https://en.wikipedia.org/wiki/Two's_complement (2) http://api.zeromq.org/4-2:zmq-msg-recv On 10/30/2017 02:13 PM, Dimitris Chloupis wrote:

I have no idea what you mean by "2's complement" 

In any case bare in mind that UFFI has a limited range of C types that does support. Here you use 2 custom types , ZmqApiMessage and ZmqApiSocket , both are pointers because of * . Now these types are definetly not included with UFFI so if you have not done so you will have to   1) Define a class that inherits from FFIExternalObject and make sure your class handles the pointer properly  2) Replace the custom type with an equivelant type that is supported by UFFI

The type of the pointer does not affect the pointer itself, usually, but rather the data it points to. So a pointer knows from it type that the data consumes a x amount of bytes and is of specific type , this can help also with indexing as C arrays are nothing more than a pointer that uses the index as an offset depending on its type of x amount of bytes. 

So its crucial that you get these right or else you going have some super weird results and even crashes. 

Because if you use improper types the pointer will give access to an area of memory bigger or smaller than the inteded type . Smaller will give you corrupted data (you will be missing bytes of data), bigger may crash because it may extend to area of memory not allowed to access. 

Technically speaking you can use even incorrect types if you know what you doing because UFFI pointers have great flexibility allowing you define real time the excact position of the memory and the range. 

Bare in mind that C is a high level language (and not low level as many incorrect assume) and deal with types that is NOT a low level concept (excepts types that have to do only with the size/ amount of bits) . So the type gives crucial information to C how exactly to access the memory.  On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dellani@pobox.com <mailto:dellani@pobox.com>> wrote:

Dear uFFI experts,

I am dealing with the port of the ZeroMQ <http://smalltalkhub.com/#%21/%7Epanuw/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* message, ZmqApiSocket* socket, long flags ) )

Calling this returns the 2's complement of the return value of the external function call. Is it expected that the code calling this do the decoding of the 2'complement representation of the return value?

Cheers,

Paulo

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. 0xFFFFFFFF is a valid positive for a long, but a -1 for an int. Cheers. On Mon, Oct 30, 2017 at 4:26 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

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 PM Paulo R. Dellani <dellani@pobox.com> wrote:

...

"Two`s complement" is one possible way to represent signed integers in binary form (1).

When the message apiZmqMsgRecv: message socket: socket withFlags: flags is 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 of bytes in the received message or -1, in case of an error. Well, I was expecting to get a -1 as return value when calling the function in non-blocking mode, but it returns 0xFFFFFFFF, which happens to be the 2's complement representation of -1. At least the old code for libZMQ was not expecting that.

Cheers, Paulo

(1) https://en.wikipedia.org/wiki/Two's_complement (2) http://api.zeromq.org/4-2:zmq-msg-recv

On 10/30/2017 02:13 PM, Dimitris Chloupis wrote:

I have no idea what you mean by "2's complement"

In any case bare in mind that UFFI has a limited range of C types that does support. Here you use 2 custom types , ZmqApiMessage and ZmqApiSocket , both are pointers because of * . Now these types are definetly not included with UFFI so if you have not done so you will have to

1) Define a class that inherits from FFIExternalObject and make sure your class handles the pointer properly 2) Replace the custom type with an equivelant type that is supported by UFFI

The type of the pointer does not affect the pointer itself, usually, but rather the data it points to. So a pointer knows from it type that the data consumes a x amount of bytes and is of specific type , this can help also with indexing as C arrays are nothing more than a pointer that uses the index as an offset depending on its type of x amount of bytes.

So its crucial that you get these right or else you going have some super weird results and even crashes.

Because if you use improper types the pointer will give access to an area of memory bigger or smaller than the inteded type . Smaller will give you corrupted data (you will be missing bytes of data), bigger may crash because it may extend to area of memory not allowed to access.

Technically speaking you can use even incorrect types if you know what you doing because UFFI pointers have great flexibility allowing you define real time the excact position of the memory and the range.

Bare in mind that C is a high level language (and not low level as many incorrect assume) and deal with types that is NOT a low level concept (excepts types that have to do only with the size/ amount of bits) . So the type gives crucial information to C how exactly to access the memory. On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dellani@pobox.com> wrote:

...

Dear uFFI experts,

I am dealing with the port of the ZeroMQ <http://smalltalkhub.com/#%21/%7Epanuw/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* message, ZmqApiSocket* socket, long flags ) )

Calling this returns the 2's complement of the return value of the external function call. Is it expected that the code calling this do the decoding of the 2'complement representation of the return value?

Cheers,

Paulo

-- Pablo Tesone. tesonep@gmail.com