"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 <dell...@pobox.com > <mailto:dell...@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 >
