Re: MSFT compiler fixes + misc

> > A thought about this - how about converting pgpiperead() and
> > pgpipewrite() into functions intead of macros (on win32 - still
> > redifining them on != win32), mimicking the behaviour of read() and
> > write()?
>
> And #def'ing them to be read + write under win32? Don't want
> to change every instance of read/write.

No.
#def'ing them to be read + write under non-win32. As is done today.


It would change (in port.h):
#ifndef WIN32
#define pgpipe(a)                       pipe(a)
#define piperead(a,b,c)         read(a,b,c)
#define pipewrite(a,b,c)        write(a,b,c)
#else
extern int pgpipe(int handles[2]);
#define piperead(a,b,c)         recv(a,b,c,0)
#define pipewrite(a,b,c)        send(a,b,c,0)
#endif

to

#ifndef WIN32
#define pgpipe(a)                       pipe(a)
#define piperead(a,b,c)         read(a,b,c)
#define pipewrite(a,b,c)        write(a,b,c)
#else
extern int pgpipe(int handles[2]);
extern int piperead(a,b,c);
extern int pipewrite(a,b,c);
#endif

And then put piperead() and pipewrite() along with pgpipe() in the C
file. (Naturally, arguments with the correct syntax, but you get the
idea)


> > Then we could do awya with the #ifdefs at the points where
> its used,
> > and just expect the normal Unix behaviour?
>
> I don't see that we do have any #ifdefs where its used.

pgstat.c, inside the main loop.
#ifdef WIN32
if (WSAGetLastError() == WSAECONNRESET) /* EOF on the pipe! (win32
socket based implementation) */
{
    pipeEOF = true;
     break;
}
#endif

There's where I notived it. That might be the only place, though -
haven't checked further. If it's the only case, then it's not such a big
deal.
But it might come back to bite us in the future - since it currently
does not actually implement "expected behaviour" of a pipe.


//Magnus