[Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError

[noreply@sourceforge.net]

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: 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?


Follow-Ups:

Date: 2001-Feb-18 14:15
By: effbot

Comment:
Okay, I just checked in a new version of DecodeUnicodeEscape (still not
100% happy with it, but it's better than before) /F
-------------------------------------------------------

Date: 2001-Feb-18 12:09
By: tim_one

Comment:
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>.
-------------------------------------------------------

Date: 2001-Feb-18 11:35
By: effbot

Comment:
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
-------------------------------------------------------

Date: 2001-Feb-18 08:34
By: tim_one

Comment:
/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?
-------------------------------------------------------

Date: 2001-Feb-18 03:46
By: effbot

Comment:
thanks for spotting the typo.  just wish I knew why
this didn't show up on any other platform...
-------------------------------------------------------

Date: 2001-Feb-17 14:37
By: zessin_5

Comment:
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.
-------------------------------------------------------

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
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.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470