Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] sa_family_t in cygwin compile of cvs

From: deststar <deststar(at)blueyonder(dot)co(dot)uk>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Jason Tishler <jason(at)tishler(dot)net>, pgsql-hackers(at)postgresql(dot)org,pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [HACKERS] sa_family_t in cygwin compile of cvs
Date: 2003-06-18 07:30:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-cygwinpgsql-hackers
Sorry didn't see it (& still can't in my inbox - where was it sent?)
Mine was a hack based on reading that sa_family_t should be 16 bits (in 
RFC 2553 IIRC) to solve a cygwin specific problem.
If you have a general solution then that is much better than mine
thank you,
- Stuart

Bruce Momjian wrote:
> I am confused why you didn't like the following patch I posted, which
> pulls the family data type length right out of the structure, rather than
> having to configure it for every OS that doesn't have sa_family_t?
> ---------------------------------------------------------------------------
> deststar wrote:
>>Jason Tishler wrote:
>>>On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote:
>>>>On cygwin sa_family_t was undeclared, adding the following line:
>>>>typedef unsigned short sa_family_t;
>>>>to both:
>>>Isn't the attached or fixing Cygwin itself a better approach?
>>Yes it does seem better, attached is a proposed patch to cygwin.h & 
>> (incase cygwin gets it in future)
>>Have tested with make installcheck & it works fine.
>>If you see no problems I will sumit to patches

In response to

pgsql-cygwin by date

Next:From: Shmuel A. KahnDate: 2003-06-18 09:51:40
Subject: Can't get postmaster to run :-(
Previous:From: Bruno Wolff IIIDate: 2003-06-18 04:07:17
Subject: Re: ss_family in hba.c

pgsql-hackers by date

Next:From: Andreas PflugDate: 2003-06-18 09:55:46
Subject: Re: pg_get_triggerdef in pg_dump
Previous:From: IvarDate: 2003-06-18 06:48:33
Subject: Is there any way to make post to newsgroups faster ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group