As far as I can see, gstdio.h doesn't include headers that would declare any of the other functions that the g_* macros expand to on Unix either. Surely the intention is that you should include <fcntl.h>, <unistd.h>, etc in addition to <glib/gstdio.h> if you want warning-free code.

To me it seems that including platform specific headers in my code defeats the whole point of portable g_ aliases and glib headers.

sys/stat.h is included there precisely to cover the other unix syscalls.

> sys/stat.h is included there precisely to cover the other unix syscalls

I think you are wrong. Remember that gstdio's purpose is to work around the file name encoding issues on Windows. The intent is not that including <glib/gstdio.h> would remove the need to include the platform-specific header with a declaration of close(), for instance. <sys/stat.h> is included in gstdio.h because otherwise including just <glib/gstdio.h> would not even compile because of the missing struct stat. But yeah, that could have been handled with just a "forward" declaration of struct stat instead.

It has been argued that gstdio.h should for completeness and uniformity wrap *all* POSIX-style calls that handle FILE pointers or file descriptors, i.e. add wrappers for close(), dup(), fwrite(), ftell() etc etc. If one would widen the scope of gstdio like this, to be a wrapper for all POSIX-style functions, then this would also be a solution to the C runtime issue on Windows. *If* this would be done, *then* gstdio.h would be all you need, and I agree that gstdio.h should include headers declaring the functions it wraps.

I may be wrong on this as I do not know the intent behing gstdio.h

However I still think that headers should make sure that APIs they expose are not causing build warnings when not relying to undocumented workarounds (a trivial one in this case but still)

Is the old bug 325249 not very similar to this?

I don't think we have any set-in-stone policy here. Bug #325249 was solved as it was because that was just what the way the person who worked on it thought best.

Btw, when you say that including <sys/stat.h> would cause functions like open() and mkdir() to become declared, I think you are wrong. Or does that really happen on your OS? At least in OpenSUSE 11.1, if I do this:

echo '#include <sys/stat.h>' | gcc -E - | grep open

I get no output. (mkdir() for instance does get declared, though.) Is it different on Ubuntu, which I guess you use?

You're right. creat() and open() are very similar so g_open leads to the same warning and both are fixed  by including fcntl.h (which I do not know if it can be relied on to be present in Win32)

echo -e '#include <glib/gstdio.h> \n void f(void){g_chmod;g_open;g_creat;g_rename;g_mkdir;g_stat;g_lstat;g_remove;g_fopen;g_freopen;}' | gcc -W `pkg-config  --cflags glib-2.0` -c -x c -

As this shows (I use Ubuntu but this should be the same on every Linux) creat and open are the only ones that are undeclared. The code just references and does not call them, hence 'statement with no effect' warnings which can be ignored.

Adding fcntl.h in gstdio makes the open and creat warnings go away :)

> Adding fcntl.h in gstdio makes the open and creat warnings go away

Yes, I am not saying that is not true. But I doubt the intent is that one should be able to compile without warnings a source file that includes just <glib/gstdio.h>. As I have said, I don't think we have any definite policy here. And as long as there isn't any such, better to leave things as they are (and require the GLib-using code to also include <fcntl.h> and/or <unistd.h> on (most?) Unixes, and <fcntl.h> and <io.h> on Windows). But I really would like to hear the opinion of Matthias or Behdad for intance.