| msg99206 - (view) |
Author: Zsolt Cserna (csernazs) * |
Date: 2010-02-11 13:40 |
| Python 2.6.4 On my system which is solaris 8/sparc, float("INFI") returns inf instead of raising ValueError, both 32 and 64-bit. (since it's case-insensitive it applies to any upper/lower combination of letters). This issue breaks test_float regression test which has a test for that value and it expects ValueError. Doing some research and debugging showed me that strtod(const char *str, char **endptr) function behaves differently on solaris 8 than linux. On solaris it stores \0 in **endptr meaning that it processed the string completely - and that's the reason why python doesn't raise ValueError. On linux, strtod() stores 'I' in **endptr, and it results the ValueError. With python 2.6.1 there's no such issue. |
|
|
| msg99214 - (view) |
Author: Mark Dickinson (mark.dickinson) *  |
Date: 2010-02-11 15:14 |
| Thanks for the report, and for the analysis. I'd call this a bug in the Solaris strtod function (though that doesn't preclude adding a workaround for Python): the C standards (well, C99, anyway; I don't have access to C89 at the moment) enumerate clearly which strings are permitted, and "INFI" isn't among them. string <-> float conversions got significantly reworked for Python 2.7 and 3.1, so there shouldn't be any problem with those versions. Are you in a position to confirm this? It would be fairly easy to work around this strtod issue by backporting the _Py_parse_inf_or_nan and case_insensitive match functions (in Python/pystrtod.c) from trunk to Python 2.6, and using those functions in PyOS_ascii_strtod. |
|
|
| msg99228 - (view) |
Author: Zsolt Cserna (csernazs) * |
Date: 2010-02-11 16:45 |
| I was not able to compile 3.1.1 due to , but with 2.7a3 it raises the expected ValueError, which is correct. Is there any chance to get those changes you mentioned backported to 2.6? |
|
|
| msg99232 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2010-02-11 18:48 |
| > Is there any chance to get those changes you mentioned backported to 2.6? Actually, to be honest, I'm not sure that backporting these changes to the release branch is a good idea. Is this bug causing problems in real code (besides the test suite)? It seems to me that this bug is fairly harmless, and the backport of the 2.7 behaviour could have unintended consequences (seems unlikely, but it's always difficult to be sure :); I'm tempted suggest closing it as a 'won't fix', especially given that it's already fixed in 2.7. |
|
|
| msg99234 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-02-11 18:58 |
| I concur with Mark. |
|
|
| msg99258 - (view) |
Author: Zsolt Cserna (csernazs) * |
Date: 2010-02-12 10:14 |
| This issue doesn't seem to cause any problems in our production code, however I haven't tested it. Btw what is the status of the solaris support? According to wiki page it should be supported by python, in real it seems it's not really supported (I mean not just this bug, but others related to solaris). |
|
|
| msg99261 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2010-02-12 10:53 |
| I agree that backporting the various parts needed to get this working would be risky and shouldn't be done. As for Solaris sure, I'm not sure. You might ask on python-dev. I get the impression that few (if any) core developers have access to a Solaris machine. |
|
|
| msg99264 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-02-12 13:10 |
| My feeling from watching bug reports is that Solaris is no less well supported than other non-linux, non-windows platforms. When you look at the number of open Solaris bug reports, also consider the number of open bug reports over all. We just don't have enough developer resources to close them all :( And yes, developer access to appropriate test systems is one of the big issues. If you have time to actively participate in resolving Solaris bugs by testing and proposing patches, my guess is you will get cooperation (and gratitude) from the dev team. |
|
|