On Sun, Jan 18, 2009 at 4:52 PM, Hin-Tak Leung hintak_leung@yahoo.co.uk wrote:
--- On Sun, 18/1/09, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
the regression test test_file.py has succeeded for years under proprietary native win32 platforms using the proprietary msvc compiler to build python.exe and python2N.dll for win32 platforms.
this particular test is therefore about testing and ensuring that \r\n handling SPECIFICALLY in O_TEXT mode is correct.
it has nothing to do with O_BINARY mode.
I already wrote that the default translation behavior (if not explicitly specified) is both compiler and runtime dependent.
nope, it's not.
The fact that msvc-compiled python working in native win32 is rather different from mingw-compiled python working in wine, isn't it?
nope, not in the slightest bit.
It differs both in the compiler used
no, it doesn't. i'm using exactly the same compiler that is used by rouman petrov, as described in http://bugs.python.org/issue3871
this is not "compile under linux and link with -lwine".
this is "compile using mingw32.exe running under msys to EXACTLY emulate the EXACT same compile as if running under win32".
and the runtime used.
.... is msvcrt and is, on wine, endeavouring to be _exactly_ the same.
therefore, this is testing msvcrt.
therefore, the bugs are in wine's implementation of msvcrt.
specifically, the O_TEXT handling.
and then some. ftell, fseek with SEEK_END after an fread - there's tons of "little" bugs.
From my experience if my memory serves (in the above bug report), Borland's compiler by-default generate code which is asymetrical - the reading code won't read what the writing code writes, in either windows or wine or both; that was very surprising to me.
well, i'm not using borland's compiler, i'm using mingw32, running it under msys+wine, so it is "exactly as if compiling on a windows system".
l.