We need a glibc expert! Anyone qualify? [Huaiyu Zhu] > ... > This is very likely to be a 2.0 bug. Or a 1.5.2 bug. I have to keep saying this stuff is a platform-dependent crap shoot, because it is (I too prefer that Python underflow silently by default, though). > Just to make sure, I have used freshly downloaded source code of > both 1.5.2 and 2.0b2, then > ./configure > make > ./python > > from math import * > exp(-746) > > I got 0.0 from 1.5.2 but OverflowError: math range error from 2.0b2. > > The file mathmodule.c has quite some differences between the two versions, > mostly related to the ANSIfication. I'm not sure where the problem is. It's not in mathmodule.c. > I haven't tried the 2.0c1 yet, as the site is not available. Can > other Unix users confirm this behavior? I went over to Guido's and forced him to try it. He sees the same behavior: after building 1.5.2 and some flavor of 2.0 w/ the same gcc and libraries, 1.5.2 Python silently returns 0 and (some flavor of) 2.0 raises OverflowError. But there is no code in Python that accounts for the difference. Running it under the debugger, the platform exp leaves errno at 0 under 1.5.2 but sets errno to ERANGE (34) under 2.0. Since the platform exp was the only conceivable cause for this difference, it's not surprising that the debugger confirmed that the platform exp is in fact the cause. So the remaining question is why the same exp from the same library has different errno behavior depending on which version of Python it's called from. *That* one we couldn't answer, after a fruitless time digging thru the Byzantine glibc source code trying to reverse engineer it. Their exp *can* display different error behavior at runtime depending on several obscure things, but they're too obscure to relate back clearly to anything Python is doing. The 2.0 behavior (set errno to ERANGE on exp underflow) appears to be what the glibc exp author believes POSIX mandates, and is one of their exp's possible runtime behaviors, and your own little C program (which you posted earlier) suggests that's the default behavior under gcc + glibc. So presumably 1.5.2 config was such as to inhibit the default behavior. However, nobody changed this on purpose, so it smells like an unintended side effect of some other (currently unknown) config change. I don't know what to do next. I can't pursue it myself, and you've seen from the lack of replies to your posts that I'm the only who'll even listen to you <wink>. Guido suggests that one big change in 2.0 is that we're including a lot more std headers than we used to. It could well be that one of those #defines some God-forsaken preprocessor symbol one of whose five meanings (documented or not) is "use POSIX-conformant libm error reporting", but which someone #include'd in 2.0 to make (who knows?) sockets work right on some other flavor of Unix. Don't know. Unix config is a mess, and so is glibc. Best hope now is for someone intimately familiar with glibc internals to jump in and own this. staring-at-the-python-source-remains-pointless-for-this-one-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4