> Guido van Rossum wrote: > > 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. [MvL] > It's not only fsync, though - there would be a lot of duplicated code if > we were to convert all function pointer passing back to function calls. Well, too bad. We could use macros instead. I believe I started taking the function address many years ago, and I just did it as a trick to save some typing, not to save code size. I think it's wrong to use it as an argument against including a function on a platform because the platform doesn't support that trick. > Also, if the system is lacking a function prototype, at the minimum, the > compiler will give a warning - at worst, we invoke the function > incorrectly, causing a crash. For fsync(), invoking it wrongly sounds unlikely. I'm sure the users of fsync() would gladly take the warning if they can have the function. 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? --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