STINNER Victor added the comment: > I think that's too late for 3.3. It's not a bug fix.
Oops, I chose 3.3 instead of 3.4. Fixed. > If we use this kind of feature, we either need to declare a minimum supported > GCC version typeof() and __builtin_types_compatible_p() were introduced to gcc in version 3.0 and 3.1.1. Do we plan to support GCC older than 3.1? :-) > (any GCC older than 10 years can be dropped IMO) GCC 3.1 was released 10 years ago. It's cheap to add a test on the GCC version to fallback on the simple "x<y?x:y" macro, but I don't know exactly which GCC versions are supported and I don't want to install a very old GCC version just to check this. > Did you detect any errors in the Python code using this change? Nope. But it avoids at least to evaluate an expression twice (if an argument is not a variable or a number, but a complex expression... like most new PyUnicode_*() macros). Even if I prefer to avoid expressions in macro arguments... > Wouldn't the compiler refuse to perform the comparison > if the types were not compatible? I don't know exactly how __builtin_types_compatible_p() compare types. At least, I can say that int and unsigned int are considered as incompatible. -- The Linux kernel uses "(void) (&_min1 == &_min2);" to check that types are compatible. I suppose that this expression is written for GCC. GCC only emits a warning, I chose Py_BUILD_ASSERT_EXPR() to emit an error instead. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15530> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
