GCC macro redefinition warnings for fwrite_unlocked

[DankRank]

When compiling any file that includes both stdio.h and config.h, GCC gives me this warning:

[ 92%] Building C object thecl/CMakeFiles/thecl.dir/thecl10.c.o
In file included from /mnt/e/Projects/Touhou/thpatch/thtk/thecl/expr.h:32:0,
                 from /mnt/e/Projects/Touhou/thpatch/thtk/thecl/thecl10.c:33:
/mnt/e/Projects/Touhou/thpatch/thtk/build/config.h:54:0: warning: "fwrite_unlocked" redefined [enabled by default]
 # define fwrite_unlocked fwrite
 ^
In file included from /usr/include/stdio.h:934:0,
                 from /mnt/e/Projects/Touhou/thpatch/thtk/thecl/thecl10.c:30:
/usr/include/x86_64-linux-gnu/bits/stdio.h:168:0: note: this is the location of the previous definition
 # define fwrite_unlocked(ptr, size, n, stream) \
 ^

Apparently bits/stdio.h contains inlined implementation of fwrite_unlocked as a macro, so it conflicts with the definition in config.h. Oddly enough this only happens to fwrite_unlocked, even though e.g. fread_unlocked is also defined as a macro in both places.

I'm not sure why those config.h defines are needed in the first place, which is why I'm posting this here instead of pushing a seemingly simple fix (#undef)

My GCC is 4.8.4 targeting x86_64-linux-gnu. My glibc is 2.19. OS: Linux subsystem on Windows 10

[DankRank]

I remembered that git blame is a thing: 34634576. It looks like this was supposed to be only applied on windows.

What I noticed while messing around with config.h.in, is that there's no warning if you first include config.h and then stdio.h, but fwrite_unlocked (the function, not the macro) doesn't get declared. It's only when you include them backwards it generates the warning. But how does this happen if config.h is the first include in every file? The answer: someone forgot include guards in config.h :V