got it.
in stdio.h:
#if !defined _MT (which it isn't...)
__CRT_INLINE int __cdecl __MINGW_NOTHROW getc (FILE* __F) { return (--__F->_cnt >= 0) ? (int) (unsigned char) *__F->_ptr++ : _filbuf (__F); }
#else /* Use library functions. */
_CRTIMP int __cdecl __MINGW_NOTHROW getc (FILE*);
#endif
consequently, MSVCRT__filbuf() is getting called _directly_. and in native MSVCRT.DLL, guess which function performs CRLF skipping, and _guess_ which function _doesn't_ perform CRLF skipping in dlls/msvcrt/file.c ?
:)
On Sat, Jan 17, 2009 at 10:58 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
but the behaviour of msvcrt wrt crlf is _definitely_ not right, as it stands, and as a result it completely screws any possibility for running python.exe under wine. completely. you can't have files that you write to, that are different from when they are read back.
ok .... this turns out to be a _really_ interesting edge-case :)
lkcl@gonzalez:~/src/python2.5-2.5.2$ ./python.exe Python 2.5.2 (r252:60911, Jan 16 2009, 22:06:34) [gcc-mingw32] on win32 Type "help", "copyright", "credits" or "license" for more information.
f = open("tst", "w") f.write("hell\n") f.write("back\n") f.close()
[80]+ Stopped ./python.exe lkcl@gonzalez:~/src/python2.5-2.5.2$ more tst hell back lkcl@gonzalez:~/src/python2.5-2.5.2$ % ./python.exe f = open("tst", "r")
x = f.readline(5) x
'hell\r' <------- wrongggggg
f.seek(0) f.readline()
'hell\n' <-------- ah _ha_. if you don't specify the length to be read....
f.seek(0) f.readline(4)
'hell'
f.readline()
'\n'
will raise this as a bug, now that there's a known test case for it.