Chris Johns <cjohns@cybertec.com.au> writes: > > So I think the configure test should be changed to define HAVE_PTON > > only if all prerequisites of its usage are met (or the entire > > function should be hidden if IPv6 is disabled). > > > > It would make Python more robust, but this is a mistake on my part. It's a trade-off between maintainability and robustness, and in this specific case, we favoured maintainability over robustness: We simply assume that the code ought to compile on all systems that have pton(3). It might be that this assumption is wrong. If so, we need to consider whether we want to support the systems for which it is wrong, in which case my proposal would be to strengthen the pton test (thus ignoring the buggy pton from the platform). In this case, I read your message that it really is your fault and not the system's (for hand-editing pyconfig.h); if you did indeed run autoconf to determine presence of pton, I'd encourage you to contribute a patch that analyses pton in more detail. 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