> > 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.
Ok, so one thing would be to decide exactly when to apply this "great rewrite of [gs]etsockopt changes". Another thing is to decide what to do with the current version. I guess I should modify the Java binding so that it will have several different cases, depending on the actual size for each given option... I don't really see any other way, given the ABI restrictions. Right? -- Gonzalo Diethelm _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
