On 8/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It was there because it's part of
>
> if (result == 0) { ... }
> else if (result == 1) { ... }
> else { assert(result == 2); ... }
>
> However the "..." in the last block contains declarations so the
> assert was moved below the declarations, and, worse, one of the
> declarations redefines 'result' (as a PyObject * initialized to NULL).
> So as soon as result==2 you'd get the failing assert.Ah, I see. I didn't realize that the result in the local block shadowed another result. I will fix that and add back in the assert so it makes sense. > I think the assert serves a purpose. Perhaps a better solution would be to add > > assert(0 <= result && result <= 2); > > right after the place where the original result is computed. Yes, I like that better too. > (BTW the name MarkupIterator_next confused me for a while until I > remembered about stringlib. I think that after this has been > backported to 2.x, we should factor out the stringlib stuff so it's > just part of unicodeobject.c. Or it needs to use a better naming > convention.) I haven't had time to review this patch yet. :-( Refactoring stringlib to be part of unicodeobject makes sense assuming stringobject goes away. The reason stringlib was there IIUC was to support (share code for) both stringobject and unicodeobject. n _______________________________________________ Python-3000-checkins mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000-checkins
