[zeromq-dev] How to use zmq_getsockopt with option ZMQ_IDENTITY_FD

[Thomas Rodgers]

yes.

using blob_t = std::basic_string<unsigned char>;

char buf[8] = { 'f', 'o', 'o', 0, 0, 0, 0, 0 };
blob_t a("foo");
blob_t b(buf, 8);

assert(a == b); // fails

I think there is another issue with all of this. By default (IIRC) the
identity is 5 bytes, so on a 64 bit platform, the passed in identity would
never be sufficient to receive sizeof(fd_t) if fd_t was in fact defined as
a UINT_PTR. I don't have a Windows machine handy so I can't verify what
sizeof(SOCKET) returns, but as many of Window's 'handle' types are in fact
pointers, I suspect this might also be an issue when fd_t is typedef'd to
SOCKET. On Posix systems, it's fine.






On Thu, Jan 8, 2015 at 8:28 AM, Peter Kleiweg <pkleiweg at xs4all.nl> wrote:

> Thomas Rodgers schreef op de 8e dag van de louwmaand van het jaar 2015:
>
> > This is an oddball API choice (and there is a bug in the implementation),
> > in that option_value* is being used as both and input and an output
> > parameter.
> >
> > The size you pass in must be be *at least* sizeof(fd_t) bytes, because it
> > will overwrite the supplied identity string with the resulting file
> > descriptor. The bug is, it does not check to see that the size of
> supplied
> > output is sufficient to hold sizeof(fd_t), so bad things (stack/heap
> > corruption) would happen if you actually passed option_len = 2.
>
> But option_len is used for retrieving the identity string:
>
>     blob_t identity= blob_t((unsigned char*)optval_,*optvallen_);
>
> Won't I get a wrong 'blob' if I use option_len = 8?
>
>
> >
> > On Thu, Jan 8, 2015 at 7:26 AM, Peter Kleiweg <pkleiweg at xs4all.nl>
> wrote:
> >
> > >
> > > Suppose the identity string is only two bytes long, I pad with
> > > zeros to get a string of eight bytes. What should the value of
> > > option_len be, 2 or 8?
>
>
>
> --
> 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/20150108/6003370f/attachment.htm>