optval pointer fix

[reqshark]

@nickdesaulniers, following up a discussion we had about getsockopt args in #46:

The third arg, optval, should be a void*. Passing a int [64] is probably not what you meant to do?

I'm pretty sure NAN or maybe node V8 is partial to char* over void*... though i guess it depends on the situtation/function we're talking about

This does work, it's just using 63 * sizeof(int) bytes more of the stack than it needs to. It works because in C arrays decay into pointers when passed to functions. So you're allocating space for 64 ints on the stack, then passing the address of the first element, which gets filled. Since it's an array of ints, only the first element is ever populated.

If you think about the C ABI, it's not possible to represent 64 ints in a single register on today's processors. That's why passing an array decays into a pointer. A kind of syntactic sugar. nn_getsockopt takes a void_, which works since optval decays into an int_.

A few lines down, there is no need to access optval[0] since we don't need optval to be an array of ints, just an int.

agreed.

[nickdesaulniers]

I'm sorry, this is not right. I will fix this when I get a chance, but the gist is we have to do something special in the case of pub sub. Se also #31 and #37.

[nickdesaulniers]

See also how get and set socket option is used within nanomsg/nanomsg. The gist is for some options we need one single integer (no arrays) (for pretty much every option) or a character array (for pub sub).

[reqshark]

oh ok, is there string use other than subscription keys/channels?

[nickdesaulniers]

I don't think so, but I need to re analyze nanomsg/nanomsg to triple check.