Proposal: Fix abstract unix sockets (#1699)
Hi, I've added proposal #1699 to fix abstract unix sockets on Linux for the network library. The patch is so far only tested under Linux (2.6.15), but should not affect Windows or other OSes which does not have AUS.
From the darcs patch comment:
Abstract Unix Socket paths begin with a zero, are not zero terminated and needs accurate socklen calculation. Thus this patch, on linux: * Calculates the exact size of sockaddr. * Pokes sockaddr correctly wrt aus. Also, due to much more socklen usage: * Switch Network.Socket to use CSockLen instead of CInt. * Cleanup surrounding code. Cheers, Lennart Kolmodin -- "The only thing that interferes with my learning is my education." -- Albert Einstein
Hi Lennart, On Sun, Sep 16, 2007 at 10:16:40AM +0100, Lennart Kolmodin wrote:
I've added proposal #1699 to fix abstract unix sockets on Linux for the network library.
You haven't suggested a deadline; between the GHC release and ICFP et al, perhaps 15 Oct would make sense?
The patch is so far only tested under Linux (2.6.15), but should not affect Windows or other OSes which does not have AUS.
So if I understand correctly, with this patch certain paths would be treated differently, but only on Linux machines? If someone tries to use AUS on a non-Linux system, will things break horribly? i.e. would it be better to have a separate package/module for this Linux-specific behaviour?
Also, due to much more socklen usage: * Switch Network.Socket to use CSockLen instead of CInt. * Cleanup surrounding code.
It would be better for code fixes and cleanup to be in a separate patch from new functionality; this part sounds like it should definitely be applied. Thanks Ian
Ian Lynagh wrote:
Hi Lennart,
On Sun, Sep 16, 2007 at 10:16:40AM +0100, Lennart Kolmodin wrote:
I've added proposal #1699 to fix abstract unix sockets on Linux for the network library.
You haven't suggested a deadline; between the GHC release and ICFP et al, perhaps 15 Oct would make sense?
Sounds excellent.
The patch is so far only tested under Linux (2.6.15), but should not affect Windows or other OSes which does not have AUS.
So if I understand correctly, with this patch certain paths would be treated differently, but only on Linux machines? If someone tries to use AUS on a non-Linux system, will things break horribly? i.e. would it be better to have a separate package/module for this Linux-specific behaviour?
I expect an exception will be thrown by 'connect' if you try to use a AUS on a non-linux box. The user only difference for the users is that they can now prefix their UnixPath with a zero. So no change of the API, iirc. A technique previously used is to create a new constructor for AUS and simply not expose it on systems that doesn't support it. This requires the portability-aware devs to #ifdef on the target platform.
Also, due to much more socklen usage: * Switch Network.Socket to use CSockLen instead of CInt. * Cleanup surrounding code.
It would be better for code fixes and cleanup to be in a separate patch from new functionality; this part sounds like it should definitely be applied.
Right, yes. The reason I didn't was because I discovered things needed to be fixed once I already had changed other stuff... aye, lazy, yes... Cheers, Lennart Kolmodin -- "The only thing that interferes with my learning is my education." -- Albert Einstein
participants (2)
-
Ian Lynagh -
Lennart Kolmodin