On Mon, Nov 22, 2010 at 10:50:14PM +0100, Matthias Bolte wrote:
> 2010/11/22 Eric Blake <eblake@xxxxxxxxxx>:
> > On 11/22/2010 01:42 PM, Matthias Bolte wrote:
> >>>> This doesn't entirely make any sense to me. GNUTLS also uses GNULIB,
> >>>> including all its socket wrappers for send/recv. If the push/pull
> >>>> function is NULL, gnulib does this
> >>>>
> >>>> Â Â Âif (session->internals._gnutls_push_func == NULL)
> >>>> Â Â Â Â{
> >>>> Â Â Â Â Âi = send (GNUTLS_POINTER_TO_INT (fd), &ptr[n - left], left, 0);
> >>>>
> >>
> >> Okay, yes GnuTLS uses gnulib, but they explicitly don't use gnulib's
> >> replacements for send() and recv() on Windows. See
> >> lib/gnutls_buffers.c:
> >>
> >> /* We need to disable gnulib's replacement wrappers to get native
> >> Â ÂWindows interfaces. */
> >> #undef recv
> >> #undef send
> >>
> >> GnuTLS decided to use the native Windows versions of send() and
> >> recv(). This cannot be changed, as that would break existing
> >> applications using GnuTLS on Windows relying on GnuTLS using the
> >> native Windows versions of send() and recv(). Therefore, I think my
> >> patch is necessary, as libvirt requires GnuTLS to use gnulib's
> >> replacement functions.
> >
> > Makes sense to me. ÂHowever, why the double cast?
> >
> > +#if HAVE_WINSOCK2_H
> > +static ssize_t
> > +custom_gnutls_push(void *s, const void *buf, size_t len)
> > +{
> > + Â Âreturn send((int)(long)s, buf, len, 0);
> > +}
> > +
> > +static ssize_t
> > +custom_gnutls_pull(void *s, void *buf, size_t len)
> > +{
> > + Â Âreturn recv((int)(long)s, buf, len, 0);
> > +}
> > +#endif
> >
> > Wouldn't send((size_t)s, ...) be better than send((int)(long)s,...)?
> >
>
> I just used what'a in curl, as directly casting from void* to int
> would give this error on 64bit platform:
>
> error: cast from pointer to integer of different size [-Wpointer-to-int-cast]
>
> (Yes, this is tested on Linux 64bit, as I didn't setup mingw-w64 yet)
>
> Casting to size_t works too.
>
> Here's a v2 that casts to size_t and has an improved commit message.
ACK, that makes sense now.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list