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