On linux-elf:


pqcomm.c: In function `StreamServerPort':
pqcomm.c:605: structure has no member named `sun_len'
pqcomm.c: In function `StreamOpen':
pqcomm.c:760: structure has no member named `sun_len'
___
 
SY, Serj

Tue, 27 Jan 1998 11:49:33 +0300
Serj <fenix@am.ring.ru>
Snapshot 270198 compile error

   On linux-elf:
   pqcomm.c: In function `StreamServerPort':
   pqcomm.c:605: structure has no member named `sun_len'
   pqcomm.c: In function `StreamOpen':
   pqcomm.c:760: structure has no member named `sun_len'

Yes,
the sun_len member of struct sockaddr_un is BSD-specific.
It is not there in Linux, nor in a SVR4-system we run here.

I had hard-coded the extra offset to 1 in the UNIXSOCK_PATH macro, 
maybe 2 or 4 works OK on all systems.

      regards,
-- 
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna


27 Jan 1998 10:08:33 -0000
Goran Thyni <goran@bildbasen.se>
Re: [HACKERS] Snapshot 270198 compile error
> 
> 
>    On linux-elf:
>    pqcomm.c: In function `StreamServerPort':
>    pqcomm.c:605: structure has no member named `sun_len'
>    pqcomm.c: In function `StreamOpen':
>    pqcomm.c:760: structure has no member named `sun_len'
> 
> Yes,
> the sun_len member of struct sockaddr_un is BSD-specific.
> It is not there in Linux, nor in a SVR4-system we run here.
> 
> I had hard-coded the extra offset to 1 in the UNIXSOCK_PATH macro, 
> maybe 2 or 4 works OK on all systems.

Gee, thanks.  This does help tremendously.  The protocol overhaul person
did not have the sun_len field, thought the +1 as a mistake of counting
the trailing null and removed it.  I will apply the following patch
which should fix the situation.  One problem is that under BSD, we never
set the sun_len field, but it still seems to work, and I can't think of
a platform-safe way of doing the assignment, so I will leave it alone.

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

*** ./include/libpq/pqcomm.h.orig	Tue Jan 27 07:25:25 1998
--- ./include/libpq/pqcomm.h	Tue Jan 27 07:36:34 1998
***************
*** 35,42 ****
  
  #define	UNIXSOCK_PATH(sun,port) \
  	(sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
! 		sizeof ((sun).sun_len) + sizeof ((sun).sun_family))
! 
  
  /*
   * These manipulate the frontend/backend protocol version number.
--- 35,46 ----
  
  #define	UNIXSOCK_PATH(sun,port) \
  	(sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
! 		+ 1 + sizeof ((sun).sun_family))
! /*
!  *		+ 1 is for BSD-specific sizeof((sun).sun_len)
!  *		We never actually set sun_len, and I can't think of a
!  *		platform-safe way of doing it, but the code still works. bjm
!  */
  
  /*
   * These manipulate the frontend/backend protocol version number.


-- 
Bruce Momjian
maillist@candle.pha.pa.us

Tue, 27 Jan 1998 07:37:07 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Snapshot 270198 compile error
> 
> 
>    On linux-elf:
>    pqcomm.c: In function `StreamServerPort':
>    pqcomm.c:605: structure has no member named `sun_len'
>    pqcomm.c: In function `StreamOpen':
>    pqcomm.c:760: structure has no member named `sun_len'
> 
> Yes,
> the sun_len member of struct sockaddr_un is BSD-specific.
> It is not there in Linux, nor in a SVR4-system we run here.
> 
> I had hard-coded the extra offset to 1 in the UNIXSOCK_PATH macro, 
> maybe 2 or 4 works OK on all systems.

I have applied a patch to document the +1 in the socket length.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Tue, 27 Jan 1998 10:35:28 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Snapshot 270198 compile error
Bruce Momjian wrote:

>   #define       UNIXSOCK_PATH(sun,port) \
>         (sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
> !               + 1 + sizeof ((sun).sun_family))
> ! /*
> !  *            + 1 is for BSD-specific sizeof((sun).sun_len)
> !  *            We never actually set sun_len, and I can't think of a
> !  *            platform-safe way of doing it, but the code still works. bjm
> !  */

I don't think this is going to work.  On glibc2 you will end up with a
trailing '\0' in the socket name.  You won't be able to see it but I
think it will be there.  Is the following version portable?

#define	UNIXSOCK_PATH(sun,port) \
	(sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
	((char *)&(sun).sun_path[0] - (char *)&(sun)))

Phil

Tue, 27 Jan 1998 19:25:11 +0000
Phil Thompson <phil@river-bank.demon.co.uk>
Re: [HACKERS] Snapshot 270198 compile error
> 
> Bruce Momjian wrote:
> 
> >   #define       UNIXSOCK_PATH(sun,port) \
> >         (sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
> > !               + 1 + sizeof ((sun).sun_family))
> > ! /*
> > !  *            + 1 is for BSD-specific sizeof((sun).sun_len)
> > !  *            We never actually set sun_len, and I can't think of a
> > !  *            platform-safe way of doing it, but the code still works. bjm
> > !  */

OK, I am with you.  Even better, let's use offset().  Takes care of
possible OS padding between fields too:

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


*** ./include/libpq/pqcomm.h.orig	Tue Jan 27 14:28:27 1998
--- ./include/libpq/pqcomm.h	Tue Jan 27 14:48:15 1998
***************
*** 35,44 ****
  
  #define	UNIXSOCK_PATH(sun,port) \
  	(sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
! 		+ 1 + sizeof ((sun).sun_family))
  /*
!  *		+ 1 is for BSD-specific sizeof((sun).sun_len)
!  *		We never actually set sun_len, and I can't think of a
   *		platform-safe way of doing it, but the code still works. bjm
   */
  
--- 35,44 ----
  
  #define	UNIXSOCK_PATH(sun,port) \
  	(sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
! 		offsetof(struct sockaddr_un, sun_path))
  /*
!  *		We do this because sun_len is in BSD's struct, while others don't.
!  *		We never actually set BSD's sun_len, and I can't think of a
   *		platform-safe way of doing it, but the code still works. bjm
   */
  


-- 
Bruce Momjian
maillist@candle.pha.pa.us

Tue, 27 Jan 1998 14:50:01 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Snapshot 270198 compile error