Logged In: YES 
user_id=86307

After thinking about it some more, I realized that fp_readl
doesn’t have to do any utf8 manipulation.  If the string it
copies into the buffer does not include a \n, the buffer is
expanded and fp_readl is called again until a \n is returned
(or the end of the file is reached).  It doesn’t matter if,
during this loop, the buffer contains temporarily broken
utf8 characters.  So I’m attaching another new patch.  This
copies as many characters as fit into the buffer and saves
any overflow into a new string object (stored in tok
>decoding_buffer).  When it is called again by the loop, it
uses this overflow string to copy characters into the buffer.

I’m also attaching a zip file with a modified test_pep263.py
and some ancillary files.  To test fp_readl, python needs to
read from a file.  Perhaps it would be better to generate
temporary files rather than include these extra files. 
Also, although the tests will trigger the assert using a
debug build of the 2.4 source, I’m not getting an access
violation running regrtest against a release build (of 2.4)
– perhaps different tests are in order?