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: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-74d10329-bbfd-42e5-8995-b0e3a68c73cb 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /opt/smalltalk/pharo6.1/pharo-vm/lib/pharo/5.0-201707201942 [default: /opt/smalltalk/pharo6.1/pharo-vm/lib/pharo/5.0-201707201942/] uname -a Linux neutrino 4.13.8-100.fc25.x86_64 #1 SMP Wed Oct 18 17:10:31 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux On 10/30/2017 01:02 PM, Paulo R. Dellani 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
