[OpenSmalltalk/opensmalltalk-vm] a64e0d: Use same Win32 function prototypes in .h and .c fo...

 
  Branch: refs/heads/Cog
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: a64e0dbbcc97c76c54decd0502b98bb81d2eca02
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a64e0dbbcc97c76c54decd0502b98bb81d2eca02
  Author: Nicolas Cellier <[hidden email]>
  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.

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)