STINNER Victor added the comment: doko> One possible solution that I can see is to use AC_C_BIGENDIAN macro, either exclusively, or only when cross-compiling.
This is wrong. The macro is not used to check the endian but to check the IEEE 754 implementation. The check is important to decide if David M. Gay's algorithm for "short float representation" can be used. See pyport.h: /* If we can't guarantee 53-bit precision, don't use the code in Python/dtoa.c, but fall back to standard code. This means that repr of a float will be long (17 sig digits). Realistically, there are two things that could go wrong: (1) doubles aren't IEEE 754 doubles, or (2) we're on x86 with the rounding precision set to 64-bits (extended precision), and we don't know how to change the rounding precision. */ #if !defined(DOUBLE_IS_LITTLE_ENDIAN_IEEE754) && \ !defined(DOUBLE_IS_BIG_ENDIAN_IEEE754) && \ !defined(DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754) #define PY_NO_SHORT_FLOAT_REPR #endif /* double rounding is symptomatic of use of extended precision on x86. If we're seeing double rounding, and we don't have any mechanism available for changing the FPU rounding precision, then don't use Python/dtoa.c. */ #if defined(X87_DOUBLE_ROUNDING) && !defined(HAVE_PY_SET_53BIT_PRECISION) #define PY_NO_SHORT_FLOAT_REPR #endif -- Python 3.4 already uses AC_C_BIGENDIAN in configure.ac, see how it is used in pyport.h. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20342> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com