MSFT compiler fixes + misc

Started by Claudio Natoliover 22 years ago6 messagespatches
Jump to latest
#1Claudio Natoli
claudio.natoli@memetrics.com

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>

Attachments:

mscver.patchapplication/octet-stream; name=mscver.patchDownload+30-31
#2Magnus Hagander
magnus@hagander.net
In reply to: Claudio Natoli (#1)
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()? Then we could do awya with the #ifdefs at the points where its
used, and just expect the normal Unix behaviour?

//Magnus

Show quoted text

-----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>
#3Claudio Natoli
claudio.natoli@memetrics.com
In reply to: Magnus Hagander (#2)
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.

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>
#4Bruce Momjian
bruce@momjian.us
In reply to: Claudio Natoli (#1)
Re: MSFT compiler fixes + misc

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
#5Magnus Hagander
magnus@hagander.net
In reply to: Bruce Momjian (#4)
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

#6Claudio Natoli
claudio.natoli@memetrics.com
In reply to: Magnus Hagander (#5)
Re: MSFT compiler fixes + misc

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