[zeromq-dev] Types for options in [gs]etsockopt()
Pieter Hintjens
ph at imatix.com
Fri Oct 1 19:25:46 CEST 2010
On Fri, Oct 1, 2010 at 7:20 PM, gonzalo diethelm <gdiethelm at dcv.cl> wrote:
> There are five cases for the types declared for options in
> [gs]etsockopt():
>
> 1. Can we make all of them 32 OR 64 bits? Or do we really need to have
> some be 32 bits and some be 64 bits?
They should all be 64 bits to avoid any future changes.
> 2. Can we make all of them signed OR unsigned? Or de we really need to
> have some be unsigned and some be signed / unspecified (this last looks
> like a bad idea)?
They should all be unsigned because none of them have any semantics
for negative values.
> 3. Can we change the typedefs (or include new ones) so that the
> signedness is explicit (sint32_t, sint64_t, etc., rather than / in
> addition to int32_t, int64_t, etc.)?
Most probably.
> 4. Can we choose a specific size (perhaps 64 bits) and signedness
> (perhaps unsigned) for ZMQ_FD?
Yes.
> In short, a simple (but perhaps incorrect) proposal would be to have all
> of them be unsigned 64 bits, using uint64_t.
Totally agree.
> When we reach consensus, I can do the changes to the code.
This is already on the roadmap for 3.0: http://www.zeromq.org/docs:3-0
Since it's an API change it would have to be done for 3.0 unless
there's consensus from binding maintainers that this counts as a
'minor change' in which case it could go into 2.1 now.
I'd see this going in 2.2.0. It will cause warnings in a bunch
of existing code though it'll be easy to find and fix those.
-
Pieter Hintjens
iMatix - www.imatix.com
More information about the zeromq-dev
mailing list