on 25/01/2012 15:23 David Chisnall said the following: > On 22 Jan 2012, at 19:25, David Schultz wrote: >> Technically it's a problem with python. If you ask for a strict >> POSIX environment (doesn't matter what version) and also #include >> a non-POSIX header, there's no guarantee about what you'll get. >> I've CC'd the xlocale author in case he wants to comment or >> voluntarily make xlocale work in an otherwise strict POSIX >> environment, but that's not officially supported. > > The problem is really with glibc, which uses these macros in the opposite way > to everyone else (glibc thinks defining these macros means expose > functionality from this standard, don't expose it otherwise, everyone else > thinks they mean expose only the things defined by this standard). This > makes writing portable code a pain and, while I'd usually be keen to blame > Python for everything, in this case I sympathise with their problem.
Thank you for the insights. > Would defining locale_t and the related functions in xlocale.h if we are in a > mode where they are not normally exposed fix the problem? I think that this should work. -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "[email protected]"
