Re: [HACKERS] 0x1A in control file on Windows

ITAGAKI Takahiro wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
>> ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
>>> We probably need to add PG_BINARY when we open control files
>>> because 0x1A is an end-of-file marker on Windows.
>> Well, why is that a bug?  If the platform is so silly as to define text
>> files that way, who are we to argue?
> 
> Google says it is for for backward compatibility with CP/M
>     http://en.wikipedia.org/wiki/End-of-file
> and adding O_BINARY is the answer.
>     http://codenewbie.com/forum/standard-c-c/1208-binary-i-o-file-reading-0x1a-trouble.html

Yes, apparently that's exactly why we have PG_BINARY, see c.h:

> /*
>  *    NOTE:  this is also used for opening text files.
>  *    WIN32 treats Control-Z as EOF in files opened in text mode.
>  *    Therefore, we open files in binary mode on Win32 so we can read
>  *    literal control-Z.    The other affect is that we see CRLF, but
>  *    that is OK because we can already handle those cleanly.
>  */
> #if defined(WIN32) || defined(__CYGWIN__)
> #define PG_BINARY    O_BINARY
> #define PG_BINARY_A "ab"
> #define PG_BINARY_R "rb"
> #define PG_BINARY_W "wb"
> #else
> #define PG_BINARY    0
> #define PG_BINARY_A "a"
> #define PG_BINARY_R "r"
> #define PG_BINARY_W "w"
> #endif

I don't see anything wrong with the patch, but I wonder if there's more 
open() calls that need the same treatment? Like the one in 
pg_resetxlog.c/ReadControlFile().

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com