[Bug 47729] Support file transfer on windows.
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Mar 22 19:31:46 CET 2012
https://bugs.freedesktop.org/show_bug.cgi?id=47729
Olli Salli <olli.salli at collabora.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard| |review-
CC| |olli.salli at collabora.co.uk
--- Comment #2 from Olli Salli <olli.salli at collabora.co.uk> 2012-03-22 11:31:46 PDT ---
Okay, some mistakes spotted
> #ifdef G_OS_WIN32
> struct sockaddr_in addr;
> #else
> struct sockaddr_un addr;
> #endif
is followed by
> new_fd = accept (g_io_channel_unix_get_fd (source),
> (struct sockaddr *) &addr, &addrlen);
This code is wrong on Unix too - it always uses a sockaddr_un to store the peer
address, even when the socket is actually a IPv4 or a IPv6 socket. But it's
also wrong on Windows - it might use the IPv4 address struct to store a IPv6
address, which'll surely lead to corrupted stack because IPv6 addresses are
significantly longer.
the addr variable is not actually read in the function after accept stores the
address in it - and is not passed anywhere - so the easiest fix is to just
remove the addr variable and pass NULL as the two latter arguments to accept().
Note that despite the name, g_io_channel_unix_get_fd is really the correct
function to use even on Windows... From GLib docs:
"On Windows this function returns the file descriptor or socket of the
GIOChannel."
However, this is not right:
> #ifdef G_OS_WIN32
> channel = g_io_channel_win32_new_fd (new_fd);
new_fd is a socket, so you must use g_io_channel_win32_new_socket so the
correct IO implementation in GLib is used (it really has to be different for
sockets and files on Windows :()
Also, in get_socket_channel():
> fd = g_socket_get_fd (sock);
> io_channel = g_io_channel_unix_new (fd);
Here as well, instead of the unix_new() call we must use win32_new_socket() on
windows.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
More information about the telepathy-bugs
mailing list