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 <dell...@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 <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 >> > >
