Re: New user: Windows, Postgresql, Python - Mailing list pgsql-general

From Michael Fuhr
Subject Re: New user: Windows, Postgresql, Python
Date
Msg-id 20050316154422.GA24735@winnie.fuhr.org
Whole thread Raw
In response to Re: New user: Windows, Postgresql, Python  (Marco Colombo <pgsql@esiway.net>)
Responses Re: New user: Windows, Postgresql, Python
List pgsql-general
On Wed, Mar 16, 2005 at 04:17:51PM +0100, Marco Colombo wrote:
>
>     aprogram = "x = 1\nprint x\n";
>     printf(aprogram);
>     PyRun_SimpleString(aprogram);
>
> See? THIS program requires compile-time or run-time checks. You
> can't run it on Windows, or Mac: it'll write garbage to the screen
> (something that looks like garbage, that is).

Are you sure about that?  It's been forever since I programmed in
a Microsoft environment, but as I recall, I/O streams opened in
"text mode" do automatic translations between \n and \r\n.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt_fopen.2c_._wfopen.asp

"Also, in text mode, carriage return-linefeed combinations are
translated into single linefeeds on input, and linefeed characters
are translated to carriage return-linefeed combinations on output."

I didn't look up Mac behavior but I'd be surprised if it didn't
offer the same "text mode" and "binary mode" behaviors.  It's
annoying that these platforms use different line endings, but at
least their implementations of standard C libraries offer a way to
hide that difference from the programmer.

> Now something strikes me... in his tests, Paul tried my program and
> the output looks identical to Linux. Now... I was expecting
> program1 (the one with just \n) do display badly under Windows.
> Am I missing something? Does C runtime support in Windows convert
> \n into \r\n automatically in printf()?  If so, I'm on the wrong track.
> It may do the same with scanf() and other stdio functions.

I think that's exactly what happens with I/O streams in "text mode."

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: plPerl subroutine
Next
From: Harald Fuchs
Date:
Subject: Re: plPerl subroutine