Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: a64e0dbbcc97c76c54decd0502b98bb81d2eca02 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a64e0dbbcc97c76c54d... Author: Nicolas Cellier nicolas.cellier@sirehna.com Date: 2016-07-07 (Thu, 07 Jul 2016)
Changed paths: M platforms/win32/plugins/SecurityPlugin/sqWin32Security.c M platforms/win32/plugins/SocketPlugin/sqWin32NewNet.c M platforms/win32/vm/sqPlatformSpecific.h
Log Message: ----------- Use same Win32 function prototypes in .h and .c for X64 compatibility (sqInt vs int)
Note: for most network function a 32bits address and port would do, we don't need 64bits. But changing int -> sqint is less intrusive (no change required in VMMaker)
Aren't many of these network primitives that are supposed to take a 32-bit ipv4 address as param? (Usually passed from image to the wrapper prim as width 4 byte-arrays)
Not sure how sqInt sqSocketRemoteAddress(SocketPtr s) is supposed to return a useful result from ntohl when provided a 64-bit integer...
TL;DR I'm no expert, but it seems to me it might be the header which is in use of fixes for many of these network primitives.
-- View this message in context: http://forum.world.st/OpenSmalltalk-opensmalltalk-vm-a64e0d-Use-same-Win32-f... Sent from the Squeak VM mailing list archive at Nabble.com.
If not, it begs the question; are there equivalents for ntoh*/hton* that let you convert platform width numbers in the same way you can use %z in printf? (Which, amazingly, is also supported in VS2015 /tc mode, their C99 support really improved in VS2013... Sure, the code generated if you try to, say, use fminf in a loop is still abysmal, but hey, at least it doesn't raise an error anymore)
-- View this message in context: http://forum.world.st/OpenSmalltalk-opensmalltalk-vm-a64e0d-Use-same-Win32-f... Sent from the Squeak VM mailing list archive at Nabble.com.
Hi Henrik, about sqInt vs 32bits ipv4 address, I had same questions. Currently the SocketPlugin is a SmartSyntaxInterpreterPlugin. That means that most types are automagically inferred and we hardly can interfer...
For win32 IA32 (x86) that does not change a thing, sqInt is int. For win32 x64, yes we pass 64bits integer via sqInt. But then htonl(sqInt) will truncate the sqInt to 32bits. That's not the cleanest thing, and it may issue a compiler warning. But it should work.
2016-07-07 22:59 GMT+02:00 Henrik Sperre Johansen < henrik.s.johansen@veloxit.no>:
If not, it begs the question; are there equivalents for ntoh*/hton* that let you convert platform width numbers in the same way you can use %z in printf? (Which, amazingly, is also supported in VS2015 /tc mode, their C99 support really improved in VS2013... Sure, the code generated if you try to, say, use fminf in a loop is still abysmal, but hey, at least it doesn't raise an error anymore)
-- View this message in context: http://forum.world.st/OpenSmalltalk-opensmalltalk-vm-a64e0d-Use-same-Win32-f... Sent from the Squeak VM mailing list archive at Nabble.com.
vm-dev@lists.squeakfoundation.org