Guido van Rossum wrote: > Is there really no function prototype in the system headers for > fsync() on those systems, or don't we see it because we're using > feature selection macros (isn't that the right term?) that hide it? I really can't answer that for all systems that lost fsync; I only know about a single one. I earlier said it was Redhat, but I recalled that incorrectly; it was "a 2-year-old Linux box running slackware" (no idea what slackware version). It is also unclear what specific version of the C library headers where installed on the system; the compiler is gcc 2.7.2. On that system, fsync is only available if __USE_BSD is defined, see python.org/sf/800710. So on the surface, it looks like a feature selection macro which we fail to define (_BSD_SOURCE), instead of a feature selection macro that we do define. OTOH, it might be that the definition of _XOPEN_SOURCE on that system would cause __USE_BSD not to be defined - I don't have a copy of features.h of the particular system. In recent glibc versions, fsync is declared if either __USE_BSD or __USE_XOPEN is defined. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4