It would make it easier for people who build GLib-using code using recent Microsoft compilers (Visual C++ 2003, 2005 and 2008) if there were "gstdio" wrappers for all C library functions that pass file descriptors (including the file descriptor that is a member in FILE structs).
Another thing that would benefit from more wrappers would be >2GB file support on Windows. So I suggest adding the wrappers listed at the end. On G_OS_UNIX they would simply be #defines, like most of the current ones in gstdio.h. Would this be acceptable? Background information: The problem that this would help solve is caused by the unfortunate fact that there are several C libraries (as shared libraries) on Windows The GNU toolchain ("MinGW") builds code that uses the msvcrt.dll C library, and the prebuilt GLib (and GTK+) binaries on ftp.gnome.org are built with MinGW. Recent Microsoft compilers (the last three versions, after the venerable MSVC6) each build code that use a C library that is specific to the compiler version (msvcr71.dll, msvcr80.dll, msvcr90.dll). "file descriptors" (the small integers as returned and used by the open(), read(), write(), fdopen() etc functions) are references to data in the C library instance, not the operating system. So for instance the file descriptor returned by g_file_open_temp() can not be passed to write() in user code compiled by Microsoft Visual C++ 200x. The original rationale for the gstdio wrappers was the file name issue: file names on Windows are actually in Unicode, but the strings one passed to the "normal" functions like open(), mkdir() etc are in an encoding specific to the Windows localisation on the machine (the "system code page"), and can not express all possible file names. To handle all possible file names, one must use the "wide" (wchar_t) versions of these functions. Thus the gstdio wrappers, and all other GLib functions that return file names or take file name parameters, use UTF-8 on Windows. GLib converts the names between wide character strings and UTF-8 and calls the wide character API. Adding wrappers because of the file descriptor issue would mean that the name of the gstdio.h header is even more misleading than today (not all functions wrapped in it have anything to do with stdio). So probably it should be renamed to gwrappers.h. gstdio.h can not be removed, obviously, but it would not be "advertised" in documentation any longer and it would just #include <glib/gwrappers.h>. The list of new wrappers: g_read(), g_write(), g_close(), g_seek(), g_tell(), g_dup(), g_dup2(), g_fileno(), g_pipe(), g_ftruncate() g_stdin, g_stdout, g_stderr g_fdopen(), g_setvbuf(), g_setbuf(), g_fread(), g_getc(), g_fgetc(), g_putc(), g_fputc(), g_fwrite(), g_scanf(), g_fscanf(), g_feof(), g_ferror(), g_fseek(), g_ftell(), g_rewind(), g_fflush(), g_fclose() g_popen(), g_pclose(); Did I forget some? g_printf(), g_fprintf(), g_vprintf(), and g_vfprintf() already exist, and they function fine as is, no separate new wrappers for them are needed. g_stdin, g_stdout and g_stderr would on Windows be macros that expand to calls to functions g_win32_get_stdin() etc that return the corresponding FILE pointers in the C library GLib uses. On POSIX they would just expand to stdin, stdout and stderr. g_seek() and g_fseek() would take gint64 offsets. --tml _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list