Bug 4025 – Making network with the std.stdio.File interface

I've written a small module that opens a network connection, then wraps it in the File struct, allowing you to use the byLine, etc., ranges on it, as well as writef/readln/etc. It is Linux only, but should be pretty easy to port to other operating systems. Ideally, I'd like to eventually be able to use File for talking to processes too, on all D platforms. Here's the code I have for now: ============== public import std.stdio; import std.string; import std.conv; version(linux): import std.c.linux.linux; import std.c.linux.socket; alias std.c.linux.socket sock; alias std.c.linux.linux linux; enum int PF_INET = 2; enum int AF_INET = PF_INET; extern(C) FILE* fdopen(int, const(char)*); File openNetwork(string host, ushort port) { hostent* h; sockaddr_in addr; h = gethostbyname(std.string.toStringz(host)); if(h is null) throw new StdioException("gethostbyname"); int s = socket(PF_INET, SOCK_STREAM, 0); if(s == -1) throw new StdioException("socket"); scope(failure) close(s); addr.sin_family = AF_INET; addr.sin_port = htons(port); std.c.string.memcpy(&addr.sin_addr.s_addr, h.h_addr, h.h_length); if(sock.connect(s, cast(sockaddr*) &addr, addr.sizeof) == -1) throw new StdioException("Connect failed"); FILE* fp = fdopen(s, "w+".ptr); File f; auto imp = new File.Impl(fp, 1, host ~ ":" ~ to!string(port)); f.p = imp; return f; }

Some thoughts: * The concept is POSIX-only. Windows uses different APIs and handles for files and network connections. * I'm not sure why you used the C socket functions when you could have used std.socket for the setup and obtained the handle. This could have shortened the code considerably. (One drawback against using std.socket I can see is that its destructor closes the socket, so you must maintain a reference to the Socket object.) * Perhaps std.stdio.File should just have public constructors which accept a FILE* or (on POSIX) a file descriptor. This would eliminate the need for such dedicated code, and instead provide better general support (for pipes and whatever else file descriptors are used for). * Alternatively, there's always std.socketstream...

Hell no. Network can be done in a multitude of ways and putting the awkward LibC buffering on top of it is the last thing we'd want. Especially in std. There is now quite a few better things on Dub that does network and I/O. All that aside - in a Dub package this addition might be simple thing that will find its users.