Обсуждение: Re: Unixware 713 probs

Поиск
Список
Период
Сортировка

Re: Unixware 713 probs

От
Larry Rosenman
Дата:

--On Sunday, September 07, 2003 14:19:00 -0500 Larry Rosenman
<ler@lerctr.org> wrote:

>
>
> --On Sunday, September 07, 2003 20:22:30 +0200 ohp@pyrenet.fr wrote:
>
> [snip]
>
>> /usr/local/bin/gmake -C libpq all
>> gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
>> cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include  -c -o
>> ip.o ip.c UX:acomp: ERROR: "ip.c", line 416: Syntax error before or at: .
>> UX:acomp: WARNING: "ip.c", line 419: left operand of "." must be
>> struct/union object UX:acomp: WARNING: "ip.c", line 427: left operand of
>> "." must be struct/union object UX:acomp: WARNING: "ip.c", line 428: left
>> operand of "." must be struct/union object UX:acomp: WARNING: "ip.c",
>> line 429: left operand of "." must be struct/union object UX:acomp:
>> WARNING: "ip.c", line 430: left operand of "." must be struct/union
>> object UX:acomp: ERROR: "ip.c", line 451: Syntax error before or at: .
>> UX:acomp: ERROR: "ip.c", line 452: invalid type combination
>> UX:acomp: WARNING: "ip.c", line 455: left operand of "." must be
>> struct/union object UX:acomp: WARNING: "ip.c", line 464: left operand of
>> "." must be struct/union object UX:acomp: WARNING: "ip.c", line 465: left
>> operand of "." must be struct/union object UX:acomp: WARNING: "ip.c",
>> line 466: left operand of "." must be struct/union object UX:acomp:
> line 416 is:
>
> int32          s_addr;
>
> s_addr is seen by the compiler as:
>
> uint32           __S_un . __S_addr ;
>
>
> We need to pick another name.
>
> LER
Here's a quickie patch I did to fix it.

Index: src/backend/libpq/ip.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/ip.c,v
retrieving revision 1.21
diff -u -r1.21 ip.c
--- src/backend/libpq/ip.c    5 Sep 2003 23:07:21 -0000    1.21
+++ src/backend/libpq/ip.c    7 Sep 2003 19:36:06 -0000
@@ -413,10 +413,10 @@
 {
     struct sockaddr_in addr4;
     struct sockaddr_in6 addr6;
-    uint32        s_addr;
+    uint32        pg_s_addr;

     memcpy(&addr4, addr, sizeof(addr4));
-    s_addr = ntohl(addr4.sin_addr.s_addr);
+    pg_s_addr = ntohl(addr4.sin_addr.s_addr);

     memset(&addr6, 0, sizeof(addr6));

@@ -424,10 +424,10 @@

     addr6.sin6_addr.s6_addr[10] = 0xff;
     addr6.sin6_addr.s6_addr[11] = 0xff;
-    addr6.sin6_addr.s6_addr[12] = (s_addr >> 24) & 0xFF;
-    addr6.sin6_addr.s6_addr[13] = (s_addr >> 16) & 0xFF;
-    addr6.sin6_addr.s6_addr[14] = (s_addr >> 8) & 0xFF;
-    addr6.sin6_addr.s6_addr[15] = (s_addr) & 0xFF;
+    addr6.sin6_addr.s6_addr[12] = (pg_s_addr >> 24) & 0xFF;
+    addr6.sin6_addr.s6_addr[13] = (pg_s_addr >> 16) & 0xFF;
+    addr6.sin6_addr.s6_addr[14] = (pg_s_addr >> 8) & 0xFF;
+    addr6.sin6_addr.s6_addr[15] = (pg_s_addr) & 0xFF;

     memcpy(addr, &addr6, sizeof(addr6));
 }
@@ -448,11 +448,11 @@
 {
     struct sockaddr_in addr4;
     struct sockaddr_in6 addr6;
-    uint32        s_addr;
+    uint32        pg_s_addr;
     int            i;

     memcpy(&addr4, addr, sizeof(addr4));
-    s_addr = ntohl(addr4.sin_addr.s_addr);
+    pg_s_addr = ntohl(addr4.sin_addr.s_addr);

     memset(&addr6, 0, sizeof(addr6));

@@ -461,10 +461,10 @@
     for (i = 0; i < 12; i++)
         addr6.sin6_addr.s6_addr[i] = 0xff;

-    addr6.sin6_addr.s6_addr[12] = (s_addr >> 24) & 0xFF;
-    addr6.sin6_addr.s6_addr[13] = (s_addr >> 16) & 0xFF;
-    addr6.sin6_addr.s6_addr[14] = (s_addr >> 8) & 0xFF;
-    addr6.sin6_addr.s6_addr[15] = (s_addr) & 0xFF;
+    addr6.sin6_addr.s6_addr[12] = (pg_s_addr >> 24) & 0xFF;
+    addr6.sin6_addr.s6_addr[13] = (pg_s_addr >> 16) & 0xFF;
+    addr6.sin6_addr.s6_addr[14] = (pg_s_addr >> 8) & 0xFF;
+    addr6.sin6_addr.s6_addr[15] = (pg_s_addr) & 0xFF;

     memcpy(addr, &addr6, sizeof(addr6));
 }


also on my http://www.lerctr.org/~ler/postgresql page.

--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Вложения

Re: Unixware 713 probs

От
Andreas Pflug
Дата:
Larry Rosenman wrote:

> Here's a quickie patch I did to fix it.

Patching this or not, if the function's called the backend will SEGV
either (at least on my 2.4.20 it does) because a IPV6 address is copied
in the memory space of a IPV4 address.

Regards,
Andreas



Re: Unixware 713 probs

От
Tom Lane
Дата:
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Larry Rosenman wrote:
>> Here's a quickie patch I did to fix it.

> Patching this or not, if the function's called the backend will SEGV
> either (at least on my 2.4.20 it does) because a IPV6 address is copied
> in the memory space of a IPV4 address.

I fixed that yesterday.

The s_addr name collision is unfortunate, but easily worked around;
fix committed as suggested by Larry.

            regards, tom lane

Re: Unixware 713 probs

От
Andreas Pflug
Дата:
Tom Lane wrote:

>Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
>
>>Larry Rosenman wrote:
>>
>>
>>>Here's a quickie patch I did to fix it.
>>>
>>>
>
>
>
>>Patching this or not, if the function's called the backend will SEGV
>>either (at least on my 2.4.20 it does) because a IPV6 address is copied
>>in the memory space of a IPV4 address.
>>
>>
>
>I fixed that yesterday.
>
>
Ah, didn't notice, I thought you would announce this to have it tested.
I just did and it works as expected.

Regards,
Andreas



Re: Unixware 713 probs

От
ohp@pyrenet.fr
Дата:
Thanks Tom,
I just cvs update'd and it ccompiles and regression tests pass.

I've have no time today to go further though
On Sun, 7 Sep 2003, Tom Lane wrote:

> Date: Sun, 07 Sep 2003 20:57:04 -0400
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Andreas Pflug <pgadmin@pse-consulting.de>
> Cc: Larry Rosenman <ler@lerctr.org>, pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Unixware 713 probs
>
> Andreas Pflug <pgadmin@pse-consulting.de> writes:
> > Larry Rosenman wrote:
> >> Here's a quickie patch I did to fix it.
>
> > Patching this or not, if the function's called the backend will SEGV
> > either (at least on my 2.4.20 it does) because a IPV6 address is copied
> > in the memory space of a IPV4 address.
>
> I fixed that yesterday.
>
> The s_addr name collision is unfortunate, but easily worked around;
> fix committed as suggested by Larry.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

--
Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)