>> I quite agree that it would be best to have a solution guaranteed >> to work in the future. However, the standard makes it very clear >> that these sort of behaviours may change in the future. So it not >> possible to use something like _XOPEN_SOURCE >= 600 with any >> confidence. > > While that argument may be theoretically true, on OS X Tiger, in > practical terms, the value of _XOPEN_SOURCE, or even it's > definition, doesn't matter for our purposes; the tests we need to > concern ourselves with are all for _POSIX_C_SOURCE, and in > addition, the tests for that in string.h and math.h simply check to > see if it is defined. Thus, your test will do the wrong thing in > cases where _POSIX_C_SOURCE is defined to 1, or any other value, > but _XOPEN_SOURCE is not defined, or _XOPEN_SOURCE is defined to > any other value than 600 (because _POSIX_C_SOURCE will be defined > anyways). Not only in the future, but also in the present, we could > very possibly run into cases that will break your proposed header fix.
These Macros should not be defined to any old values. Any sources doing that sort of thing are clearly wrong, and they should not accommodated except as specific exceptions. Only certain values are valid. The fix I put up only changes the existing code if _POSIX_C_SOURCES is 200112L. In that case strcasecmp() and friends are most definitely in <strings.h>. and the fix must still work in all the old cases. I don't see how the fix can break anything. > Well, in most cases, we don't run into problems with this approach, > meaning that the configure test is 'good enough' in most > environments in which it is used. So I rather think the best thing > to do is to fix it when it breaks. In this case, thanks to the > Carbon fp.h problem, there's really no debate as to what the fix > must be - we simply can't have _POSIX_C_SOURCE defined for wx on > Tiger, so making sure it is undefined at the appropriate place > should fix the problem. But my suggested fix ensures that code will not break whether or not _POSIX_C_SOURCES is defined. The code without the fix only works if it is not defined. > > Otherwise, if we get rid of the configure test, we need to > construct a completely fool-proof runtime test in the headers, and > to do that, we'd have to look at every possible combination of > #ifdef's for the inclusion of these functions on every supported > platform, and then construct our own runtime test that passes in > every one of those conditions, and fails in any other. Considering > we'll probably never get it totally right this way either, and in > the meantime we may break cases where the code does already work > (in which case the patch won't be accepted anyways), I'd rather > live with the configure test for now. :-) If you really want to stick with the configure test, it seems to me that it should at least be reversed. That is test for <strings.h> first and if that works, don't bother with <string.h>. It seems to me that would be more robust. I guess it is the other way around for historical reasons. In BSD 4.3 the extensions were in <string.h>. In BSD 4.4 and subsequent they are moved to <strings.h>. So if <strings.h> works it should be right, and the systems for which it does not work are all going to be fairly geriatric by now. That way the code would be POSIX compliant even without the other fix :-)! Cheers Bill _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
