Client build of MSVC6+ patch

Hi Bruce-san, and Magnus-san.

I take out patch for this as a promise.
This is client-build support of MS-VC6+.
However, It leaves the problem of IPV6.:-(

Hi!

This patch looks a lot better to me.

What is the problem with IPV6? Did I break that with my changes to
getaddrinfo.c, or is it something else?

//Magnus

Magnus Hagander wrote:

What is the problem with IPV6? Did I break that with my changes to
getaddrinfo.c, or is it something else?

If IPv6 gets broken after all the trouble several of us went to I'll be
annoyed. :-)

cheers

andrew

Hiroshi Saito said:

Hi.

If IPv6 gets broken after all the trouble several of us went to I'll
be annoyed. :-)

Um, I think that this was the origin in problem.:-)

Why do we need to reorder the fields in the struct?

cheers

andrew

Hi.

If IPv6 gets broken after all the trouble several of us went to I'll be
annoyed. :-)

Um, I think that this was the origin in problem.:-)

Regards,
Hiroshi Saito

Hi.

If IPv6 gets broken after all the trouble several of us went to I'll
be annoyed. :-)

Um, I think that this was the origin in problem.:-)

Why do we need to reorder the fields in the struct?

Eh? Even my FreeBSD used well shows a structure object.
(FreeBSD)
/usr/include/netdb.h
struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
int ai_family; /* PF_xxx */
int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
size_t ai_addrlen; /* length of ai_addr */
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */
};

Then, It was helped actually.

Regards,
Hiroshi Saito

"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:

Why do we need to reorder the fields in the struct?

Eh? Even my FreeBSD used well shows a structure object.

The standard lists the fields in the other order:
http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html

Even though the standard doesn't say that that has to be the physical
order, every other platform besides Windows does it that way. The patch
as given is unacceptable because it *will* break other platforms (mine
for instance ;-)). If it has to be this way for Windows then we need
some sort of platform-specific #ifdef. Considering that the code works
as-is on several sorts of Windows builds, we probably need something
even more specific than that, like #if MSVC-before-version-XX.

regards, tom lane

Hi. Tom-san.

Oops, I understood it. Thank you for suggestion.
What condition is this?

Regards,
Hiroshi Saito

From: "Tom Lane"

Why do we need to reorder the fields in the struct?

Eh? Even my FreeBSD used well shows a structure object.

The standard lists the fields in the other order:
http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html

Even though the standard doesn't say that that has to be the
physical order, every other platform besides Windows does it
that way. The patch as given is unacceptable because it
*will* break other platforms (mine for instance ;-)). If it
has to be this way for Windows then we need some sort of
platform-specific #ifdef. Considering that the code works
as-is on several sorts of Windows builds, we probably need
something even more specific than that, like #if
MSVC-before-version-XX.

Haven't dug into the details, but it just feels a bit off that this
shuold be depending on the compiler. MSVC6 and MingW uses the same
runtime library, and I would've expected it to be more depending on that
than on the compiler itself?

That said, where does the problem actually show up, Hiroshi? If it's
just at runtime, I'm not so sure it works on MingW - AFAIK it's at least
not tested on the buildfarm. And I haven't tested IPV6 on newer versions
of MSVC.

//Magnus

I am thinking this patch needs to be applied, and the #ifdef test
changed to WIN32 so both MinGW and MSVC use the changed structure
ordering.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

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

Hiroshi Saito wrote:

Hi. Tom-san.

Oops, I understood it. Thank you for suggestion.
What condition is this?

Regards,
Hiroshi Saito

From: "Tom Lane"

"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:

Why do we need to reorder the fields in the struct?

Eh? Even my FreeBSD used well shows a structure object.

The standard lists the fields in the other order:
http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html

Even though the standard doesn't say that that has to be the physical
order, every other platform besides Windows does it that way. The patch
as given is unacceptable because it *will* break other platforms (mine
for instance ;-)). If it has to be this way for Windows then we need
some sort of platform-specific #ifdef. Considering that the code works
as-is on several sorts of Windows builds, we probably need something
even more specific than that, like #if MSVC-before-version-XX.

regards, tom lane

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Patch applied. Thanks.

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

Hiroshi Saito wrote:

Hi Bruce-san, and Magnus-san.

I take out patch for this as a promise.
This is client-build support of MS-VC6+.
However, It leaves the problem of IPV6.:-(

Regards,
Hiroshi Saito

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Patch applied. Change made so test is WIN32, and add comment about
different structure ordering on Win32 for IPv6 use.

Thanks.

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

Hiroshi Saito wrote:

Hi. Tom-san.

Oops, I understood it. Thank you for suggestion.
What condition is this?

Regards,
Hiroshi Saito

From: "Tom Lane"

"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:

Why do we need to reorder the fields in the struct?

Eh? Even my FreeBSD used well shows a structure object.

The standard lists the fields in the other order:
http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html

Even though the standard doesn't say that that has to be the physical
order, every other platform besides Windows does it that way. The patch
as given is unacceptable because it *will* break other platforms (mine
for instance ;-)). If it has to be this way for Windows then we need
some sort of platform-specific #ifdef. Considering that the code works
as-is on several sorts of Windows builds, we probably need something
even more specific than that, like #if MSVC-before-version-XX.

regards, tom lane

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I'm still not very happy - we never got a reply about why the reordering
was needed at all. Referring in some way to FBSD doesn't really answer
for Windows. I am currently without a Windows box I can use, so I am
dependent on asking questions.

cheers

andrew

Bruce Momjian wrote:

Andrew Dunstan wrote:

I'm still not very happy - we never got a reply about why the reordering
was needed at all. Referring in some way to FBSD doesn't really answer
for Windows. I am currently without a Windows box I can use, so I am
dependent on asking questions.

Well, in MSVC addrinfo is defined this way (as in patch) too. MSVC does
even have IPv6 detection in its header files.

--
Regards
Petr Jelinek (PJMODOS)

Petr Jelinek said:

Andrew Dunstan wrote:

I'm still not very happy - we never got a reply about why the
reordering was needed at all. Referring in some way to FBSD doesn't
really answer for Windows. I am currently without a Windows box I can
use, so I am dependent on asking questions.

Well, in MSVC addrinfo is defined this way (as in patch) too. MSVC does
even have IPv6 detection in its header files.

That's certainly a better answer.

Does the detection work at runtime, or is it static? IIRC we found that
static detection broke the binary portability on Windows.

cheers

andrew

Andrew Dunstan wrote:

Does the detection work at runtime, or is it static? IIRC we found that
static detection broke the binary portability on Windows.

It's runtime just like ours.

--
Regards
Petr Jelinek (PJMODOS)