[zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

>
> Actually, it's even worse than that. For a standard install, I can use
> only one type per platform. It has to be either SOCKET or UINT_PTR on all
> Windows platforms.


I don't know why there are two different types used on Windows, but this
aspect of fd_t has been there since the initial commit by sustrik in 2009.
ZMQ_FD has this behavior already (and has been that way since 2009 as well).

For ZMQ_FD there is a clearly defined use case; the FD is passed off to
whatever platform event demultiplexor you happen to have (epoll, kqueues,
select), and so it must be the type the underlying platform uses for these
system calls. It is not clear to me what you can practically do with the
value returned from ZMQ_IDENTITY_FD except treat it opaquely (it certainly
is not safe to do raw socket IO calls with it I would expect).

On Wed, Jan 7, 2015 at 8:16 PM, Peter Kleiweg <pkleiweg at xs4all.nl> wrote:

>
>
> Peter Kleiweg <pkleiweg at xs4all.nl> schreef op 8 januari 2015 03:08:50 CET:
> >
> >
> > Thomas Rodgers <rodgert at twrodgers.com> schreef op 8 januari 2015
> > 02:56:18 CET:
> > > FD ~= "file descriptor".
> > >
> > > fd_t, the type this option actually returns, is conditionally
> > defined
> > > to be
> > > int or SOCKET depending on platform, same as with ZMQ_FD. It is
> > > however,
> > > not the same FD that would be returned by the ZMQ_FD option (I
> > believe
> > > it
> > > is the underlying TCP file descriptor or SOCKET in this case).
> > >
> >
> > I have looked to the source.
> >
> > On non-Windows, it is an int. No problem.
> >
> > On Windows, it is either a SOCKET or a UINT_PTR. This is impossible. I
> > write a Go binding[1] based on the C API. I need to know what the type
> > is on Windows, and the C header file doesn't tell.
> >
>
> Actually, it's even worse than that. For a standard install, I can use
> only one type per platform. It has to be either SOCKET or UINT_PTR on all
> Windows platforms.
>
>
> --
> Peter Kleiweg
> http://pkleiweg.home.xs4all.nl
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150107/2d5517c8/attachment.htm>