Thread: 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.:-( Regards, Hiroshi Saito
Attachment
> 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
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
Attachment
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.:-)
>>
>
> 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" > "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
> >> 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: >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 >> >> > > >
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)