Thread: MSFT compiler fixes + misc

MSFT compiler fixes + misc

From
Claudio Natoli
Date:
For application to HEAD, following community review.

Corrects issues recently posted by Dann Corbit, allowing libpq/psql to be
built under VC++. Moves a pgstat win32 #def to port.h

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>



Attachment

Re: MSFT compiler fixes + misc

From
"Magnus Hagander"
Date:
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()? Then we could do awya with the #ifdefs at the points where its
used, and just expect the normal Unix behaviour?

//Magnus


>-----Original Message-----
>From: Claudio Natoli [mailto:claudio.natoli@memetrics.com]
>Sent: den 1 april 2004 05:06
>To: pgsql-patches@postgresql.org
>Subject: [PATCHES] MSFT compiler fixes + misc
>
>
>
>For application to HEAD, following community review.
>
>Corrects issues recently posted by Dann Corbit, allowing
>libpq/psql to be
>built under VC++. Moves a pgstat win32 #def to port.h
>
>---
>Certain disclaimers and policies apply to all email sent from
>Memetrics.
>For the full text of these disclaimers and policies see
><a
>href="http://www.memetrics.com/emailpolicy.html">http://www.mem
>etrics.com/em
>ailpolicy.html</a>
>
>
>

Re: MSFT compiler fixes + misc

From
Claudio Natoli
Date:

> 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.


> 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.


Can't help but feel I've misinterpreted your message.

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Re: MSFT compiler fixes + misc

From
Bruce Momjian
Date:
Patch applied.  Thanks.

---------------------------------------------------------------------------


Claudio Natoli wrote:
>
> For application to HEAD, following community review.
>
> Corrects issues recently posted by Dann Corbit, allowing libpq/psql to be
> built under VC++. Moves a pgstat win32 #def to port.h
>
> ---
> Certain disclaimers and policies apply to all email sent from Memetrics.
> For the full text of these disclaimers and policies see
> <a
> href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
> ailpolicy.html</a>
>
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: MSFT compiler fixes + misc

From
"Magnus Hagander"
Date:
> > 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

Re: MSFT compiler fixes + misc

From
Claudio Natoli
Date:

> [snip]
> #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)
> [snip]

Ah, now it is clear what you meant.

You want to submit the patch?

Cheers,
Claudio


---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>