GNOME Bugzilla – Bug 603473
gstdio has g_creat, g_open.. but no read/write/close
Last modified: 2009-12-02 12:49:57 UTC
I wonder why there are such functions, but there is no g_read, g_write or g_close. Is there a reason for this? It would be great if g_fdopen or g_io_channel_new_from_fd () exist too.
Read this comment in gstdio.h: /* Wrappers for C library functions that take pathname arguments. On * Unix, the pathname is a file name as it literally is in the file * system. On well-maintained systems with consistent users who know * what they are doing and no exchange of files with others this would * be a well-defined encoding, preferrably UTF-8. On Windows, the * pathname is always in UTF-8, even if that is not the on-disk * encoding, and not the encoding accepted by the C library or Win32 * API. */ This should tell you that the reason why these wrappers exist is related to file names. There is no file name being passed to read(), write() or close().
As for g_io_channel_new_from_fd(), that's what g_io_channel_unix_new() is.
The problem is that read/write/.. are posix functions which are defined in unistd.h which is only on *nix systems, and if I have to build the same code on w32 I will have to make conditional compilation to include <io.h> or <unistd.h> depending on the system. If glib aims to abstract such situations, it would be good to have some #ifdef G_OS_WIN32 #include <io.h> #else #include <unistd.h> #endif #define g_read read #define g_write write #define g_close close This way the api gets consistent and the resulting code will work everywhere without conditional compilation. In Vala, if you use the posix vapi, unistd.h is included, so it will not build on Windows. This takes sense, because Windows does not fully implements posix, and IMHO all this stuff should be managed by the GLIB API as an abstraction. Thanks for the unix_new () tip
> I will have to make conditional compilation to include <io.h> or <unistd.h> And is that then such a huge burden?
It is unnecessary, makes things more complex, more repeated code, etc..
Well, by the same reasoning one might require that including <glib.h> should also for instance make <windows.h> get included on Windows if it makes <unistd.h> get included on Unix. Or make <winsock2.h> and <ws2tcpip.h> be included on Windows and the <netinet/in.h>, <sys/socket.h> etc litany on Unix. Etc. Clearly it is unnecessary and makes things more complex to have to conditionalize inclusions of these headers in GLib-using code, too, then?