> In this specific case, it would have triggered a false alarm on some > systems. I rewrote the test for fsync to overcome a build problem on > some system, where fsync was present in the library, but not present > in the header files. Since we are taking fsync's address, this causes > a compile-time problem. So it *is* intentional that fsync is now gone > for systems on which it was previously (2.2) present. (More > specifically, fsync might disappear on systems that cannot stand > _XOPEN_SOURCE being defined) I don't like this. We're not taking fsync's address for a very good reason, just to save some code duplication. Removing fsync from those platforms just because our code-saving trick doesn't work there doesn't strike me as good service for those platforms. --Guido van Rossum (home page: http://www.python.org/~guido/)
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