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 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