Issue232817
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-02-17 13:54 by zessin_5, last changed 2022-04-10 16:03 by admin. This issue is now closed.
Messages (8) | |||
---|---|---|---|
msg3438 - (view) | Author: Uwe Zessin (zessin_5) | Date: 2001-02-17 13:54 | |
test_ucn On OpenVMS, this test fails with the following error message: test test_ucn crashed -- exceptions.AssertionError: failed to raise an exception when given a bogus character name How can I diagnose this? |
|||
msg3439 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-02-17 18:20 | |
Assigned to /F. zessin_5, look at test_ucn.py, if you want. The error in question is raised in only one place, verifying that "\N{blah}" raises UnicodeError when passed thru unicode-escape. Don't know why it's not on your platform. |
|||
msg3440 - (view) | Author: Uwe Zessin (zessin_5) | Date: 2001-02-17 22:37 | |
Here is the result from my debugging: UNICODEOBJECT.C if (!ucnhash_CAPI->getcode(start, endBrace-start, &chr)) { calls: UNICODEDATA.C: getcode(const char* name, int namelen, Py_UCS4* code) { There are 4 'return's in getcode(). After I replace the 'return -1;' with 'return 0;' I get the exceptions. |
|||
msg3441 - (view) | Author: Fredrik Lundh (effbot) * | Date: 2001-02-18 11:46 | |
thanks for spotting the typo. just wish I knew why this didn't show up on any other platform... |
|||
msg3442 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-02-18 16:34 | |
/F, I'm re-opening this until it's understood. It's clear that the test "worked" by accident before, yes? I stepped thru it ("N{blah}") in the debugger on Windows, under the old code. The reason it worked then is that, in PyUnicode_DecodeUnicodeEscape, the stack vrbl "chr" remained uninitialized all the way to label "store:", where a series of tests then checked this stack trash against various ranges. On Windows the trash happened to be the too-large-for-Unicode 0x0063f9dc, so triggered a different error by accident. Presumably under OpenVMS, the trash passed those tests by accident. Perhaps it's impossible to ever test stack trash now, but I'd feel better if the code covered its ass there anyway. You? |
|||
msg3443 - (view) | Author: Fredrik Lundh (effbot) * | Date: 2001-02-18 19:35 | |
Tim, "getcode" is supposed to set the "chr" value if it returns non-zero. After Uwe's fix, this is exactly what it does. But DecodeUnicodeEscape is rather messy; I've discovered a few other cases where it can misbehave. I'll do something about it asap. /F |
|||
msg3444 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-02-18 20:09 | |
I just had in mind initializing chr to a known-bogus value and assert'ing it doesn't still have that value when it's finally referenced, so that a reoccurrence of this (or similar) bug won't pass by accident again. I understand that the code was intended to work as you say, but better safe than to trust that all future maintainers will figure that out when they're hacking in the middle of the 200+ lines of code across which this undocumented invariant is supposed to hold. Goodness, the code even initializes p, despite that it's set again within a mere dozen lines <wink>. |
|||
msg3445 - (view) | Author: Fredrik Lundh (effbot) * | Date: 2001-02-18 22:15 | |
Okay, I just checked in a new version of DecodeUnicodeEscape (still not 100% happy with it, but it's better than before) /F |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:03:45 | admin | set | github: 33947 |
2001-02-17 13:54:13 | zessin_5 | create |