Fix Nan type missmatch warnings

[lgeiger]

I wrestled down some windows build warnings 😄

The only warning I don't know how to fix is thrown here:

c:\projects\zmq-prebuilt\node_modules\nan\nan_new.h(208): warning C4244: 'argument': conversion from 'int64_t' to 'double', possible loss of data (compiling source file ..\binding.cc) [C:\projects\zmq-prebuilt\build\zmq.vcxproj]
  ..\binding.cc(613): note: see reference to function template instantiation 'v8::Local<v8::Number> Nan::New<v8::Number,T>(A0)' being compiled
          with
          [
              T=int64_t,
              A0=int64_t
          ]
  ..\binding.cc(667): note: see reference to function template instantiation 'v8::Local<v8::Value> zmq::Socket::GetSockOpt<int64_t>(int)' being compiled
c:\projects\zmq-prebuilt\node_modules\nan\nan_new.h(208): warning C4244: 'argument': conversion from 'uint64_t' to 'double', possible loss of data (compiling source file ..\binding.cc) [C:\projects\zmq-prebuilt\build\zmq.vcxproj]
  ..\binding.cc(613): note: see reference to function template instantiation 'v8::Local<v8::Number> Nan::New<v8::Number,T>(A0)' being compiled
          with
          [
              T=uint64_t,
              A0=uint64_t
          ]
  ..\binding.cc(669): note: see reference to function template instantiation 'v8::Local<v8::Value> zmq::Socket::GetSockOpt<uint64_t>(int)' being compiled
     Creating library C:\projects\zmq-prebuilt\build\Release\zmq.lib and object C:\projects\zmq-prebuilt\build\Release\zmq.exp

[lgeiger]

Or should GetSockOpt accept int64_t?

[rgbkrk]

Well outside my expertise. 🙇 @minrk any hunches?

[minrk]

There are a few int64 options. Hopefully The docs cover it. pyzmq handles it by keeping track of a list of options that should be int64, int, bytes.

[willingc]

Nice approach in pyzmq.

[lgeiger]

@minrk Oh I see, thanks for the links.

Would it be better to keep using int64_t and change GetSockOpt and SetSockOpt to use int64_t there as well?
My C++ knowledge is rather limited 😉

[minrk]

Now that I re-read, I think I see what's going on here and int64_t should be left. This is using the same 64b of memory for all the numerical versions of GetSockOpt, but casting that address to other (potentially smaller) types based on the expected type of the option.

Since int and int64 are the same size on a 64b build, there's no problem switching. However, you should get segfaults on 32b systems, because int is only 32b and the explicit int64 and uint64 options (L667, 669 below) will try to write 64b to 32b of memory.

[lgeiger]

@minrk Thanks for the clarification 👍

I'll make a PR.

[minrk]

Arg, sorry. Now that I've read it again, this is only option, which should be an int not int64, and not optval, the result which has varying type. Everything is fine here, move along.

[lgeiger]

Even better 👍

Thanks for taking a look!

[willingc]

Gotta love C++ and type conversion.

[codecov-io]

Current coverage is 91.16% (diff: 100%)

Merging #89 into master will not change coverage

Powered by Codecov. Last update 6de94b7...2f5dd0f

[n-riesco]

r/ JustinTulloss/zeromq.node#497

[lgeiger]

@n-riesco Thanks for the link! If I read correctly this fix should be OK.