Eryk Sun added the comment:

In issue 20844 I suggested opening the file in binary mode, i.e. change the 
call to _Py_wfopen(filename, L"rb") in Modules/main.c. That would also entail 
documenting that PyRun_SimpleFileExFlags requires a FILE pointer that's opened 
in binary mode. After making this change, there's no problem parsing 
"encoding-problem-cp1252.py":

    >python --version
    Python 3.6.0a4+

    >python encoding-problem-cp1252.py
    ok

When fp_setreadl is called while parsing "encoding-problem-cp1252.py", 47 bytes 
in the FILE buffer have been read -- up to the end of the coding spec. Let's 
verify this in the debugger:

    0:000> bp python35_d!fp_setreadl
    0:000> g
    Breakpoint 0 hit
    python35_d!fp_setreadl:
    00000000`662bee00 4889542410      mov     qword ptr [rsp+10h],rdx
                                ss:000000d7`6cfeead8=000000d76cfeeaf8
    0:000> ;as /x fp @@(((python35_d!tok_state *)@rcx)->fp)
    0:000> ;as /x ptr @@(((ucrtbased!__crt_stdio_stream_data *)${fp})->_ptr)
    0:000> ;as /x base @@(((ucrtbased!__crt_stdio_stream_data *)${fp})->_base)
    0:000> ?? ${ptr} - ${base}
    int64 0n47

ftell() should return 47, but instead it returns -1. You can see this by 
opening the file in Python 2 on Windows, which uses FILE streams:

    >>> f = open('encoding-problem-cp1252.py')
    >>> f.read(47)
    '#!/usr/bin/env python\n# -*- coding: cp1252 -*-\n'
    >>> f.tell()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    IOError: [Errno 0] Error

ftell starts by getting the file position from the OS and then subtracts the 
unread bytes in the buffer. The buffer has already undergone CRLF => LF 
translation, so ftell makes an assumption that the file uses CRLF line endings 
and thus subtracts 2 bytes for each unread LF. In this case the buffer happens 
to have 48 unread LFs, so ftell returns -1, with the only actual error being a 
fundamentally flawed design in the CRT's text mode.

----------
nosy: +eryksun

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27797>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to