Mark Dickinson <dicki...@gmail.com> added the comment: > Because "pfval" in this example doesn't exist but is merely a temporary, > > there is no aliasing.
Maybe aliasing wasn't the right word to use, then. The exact rule being violated is C99 6.5, para. 7 (or C11 6.5 para. 7 if you prefer): """ An object shall have its stored value accessed only by an lvalue expression that has one of the following types: ... """ In any case, I don't think it's relevant whether the values involved are named variables or temporaries. > I don't think we could have our own floating point formatting library > if we > didn't make that assumption There are configure-time checks that determine whether that floating-point formatting library is used or not, including (amongst some other things) whether the underlying floating-point type is IEEE 754. Officially, Python shouldn't assume IEEE 754 floating-point anywhere---the core should build fine without it, and there's lots of code in the core to deal with non-IEEE 754 platforms. > And should such a platform be found, it is easy enough to disable this > code > for it. I think that's the wrong way around: the code should only be enabled in the first place when we're sure that the platform is IEEE 754. That shouldn't be hard to build into the patch, since the checks for IEEE 754 are already all over the place for other purposes. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14381> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
