Hi,
LIU Hao wrote:
> Is there a reason why dfa.c is compiled without `_POSIX_C_SOURCE`?
Yes:
* GNU packages define the compilation options once for all compilation units.
There are too many pitfalls in having different options in different
compilation units (think of the effect of -D_FILE_OFFSET_BITS=64
on 'struct stat'...).
* Some parts of a package need to access OS specific functions, some other
parts don't. But they are compiled with the same compilation options.
* On some platforms, _POSIX_C_SOURCE turns *off* OS specific facilities.
- glibc: FNM_CASEFOLD, ...
- Solaris: drand48, isascii, P_tmpdir, getc_unlocked, ...
> `_POSIX_THREAD_SAFE_FUNCTIONS` is an implementation macro that should be
> defined by unistd.h; it's not a
> feature test macro that should be defined by users of unistd.h.
What I'm doing is a workaround.
The problem is in this include chain:
uchar.h -> wchar.h -> sys/stat.h -> time.h -> unistd.h -> winsock2.h ->
windows.h
* uchar.h -> wchar.h is reasonable because uchar.h functions are often defined
in terms of wchar.h functions.
* wchar.h -> sys/stat.h is unreasonable because string related functions should
never rely on file system functions.
* sys/stat.h -> time.h is reasonable because 'struct stat' depends on whether
time_t is 32-bit or 64-bit.
* time.h -> unistd.h, on mingw, is due to 'localtime_r' and 'gmtime_r'.
* unistd.h -> winsock2.h is reasonable, because of the 'gethostname' function.
* winsock2.h -> windows.h I cannot judge.
So, in this include chain, the most unreasonable includes are
wchar.h -> sys/stat.h
time.h -> unistd.h
Bruno
