2003-04-02 02:49:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* getaddrinfo.h
|
|
|
|
|
* Support getaddrinfo() on platforms that don't have it.
|
|
|
|
|
*
|
|
|
|
|
* Note: we use our own routines on platforms that don't HAVE_STRUCT_ADDRINFO,
|
|
|
|
|
* whether or not the library routine getaddrinfo() can be found. This
|
|
|
|
|
* policy is needed because on some platforms a manually installed libbind.a
|
|
|
|
|
* may provide getaddrinfo(), yet the system headers may not provide the
|
|
|
|
|
* struct definitions needed to call it. To avoid conflict with the libbind
|
|
|
|
|
* definition in such cases, we rename our routines to pg_xxx() via macros.
|
|
|
|
|
*
|
|
|
|
|
* This code will also work on platforms where struct addrinfo is defined
|
|
|
|
|
* in the system headers but no getaddrinfo() can be located.
|
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Copyright (c) 2003-2020, PostgreSQL Global Development Group
|
2003-04-02 02:49:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/getaddrinfo.h
|
2003-04-02 02:49:28 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
2003-03-29 12:31:52 +01:00
|
|
|
#ifndef GETADDRINFO_H
|
|
|
|
|
#define GETADDRINFO_H
|
|
|
|
|
|
2003-04-02 02:49:28 +02:00
|
|
|
#include <sys/socket.h>
|
2003-03-29 12:31:52 +01:00
|
|
|
#include <netdb.h>
|
|
|
|
|
|
|
|
|
|
|
2003-08-07 18:45:21 +02:00
|
|
|
/* Various macros that ought to be in <netdb.h>, but might not be */
|
2003-04-02 02:49:28 +02:00
|
|
|
|
2003-08-07 18:45:21 +02:00
|
|
|
#ifndef EAI_FAIL
|
2005-08-25 19:51:01 +02:00
|
|
|
#ifndef WIN32
|
2005-07-27 14:44:10 +02:00
|
|
|
#define EAI_BADFLAGS (-1)
|
|
|
|
|
#define EAI_NONAME (-2)
|
|
|
|
|
#define EAI_AGAIN (-3)
|
|
|
|
|
#define EAI_FAIL (-4)
|
|
|
|
|
#define EAI_FAMILY (-6)
|
|
|
|
|
#define EAI_SOCKTYPE (-7)
|
|
|
|
|
#define EAI_SERVICE (-8)
|
|
|
|
|
#define EAI_MEMORY (-10)
|
|
|
|
|
#define EAI_SYSTEM (-11)
|
2005-10-15 04:49:52 +02:00
|
|
|
#else /* WIN32 */
|
2017-04-11 15:21:25 +02:00
|
|
|
#ifdef _MSC_VER
|
2006-07-06 04:12:32 +02:00
|
|
|
#ifndef WSA_NOT_ENOUGH_MEMORY
|
2006-10-04 02:30:14 +02:00
|
|
|
#define WSA_NOT_ENOUGH_MEMORY (WSAENOBUFS)
|
2006-07-06 04:12:32 +02:00
|
|
|
#endif
|
2006-10-04 02:30:14 +02:00
|
|
|
#define WSATYPE_NOT_FOUND (WSABASEERR+109)
|
Disble some Win32-specific code in win32-client-only builds:
I have the problem, when building by MS-VC6.
An error occurs in the 8.1.0 present source codes.
nmake -f win32.mak
..\..\port\getaddrinfo.c(244) : error C2065: 'WSA_NOT_ENOUGH_MEMORY'
..\..\port\getaddrinfo.c(342) : error C2065: 'WSATYPE_NOT_FOUND'
This is used by winsock2.h. However, Construction of a windows base is
winsock.h.
Then, Since MinGW has special environment, this is right. but, it is not
found in VC6.
Furthermore, in getaddrinfo.c, IPV6-API is used by
LoadLibraryA("ws2_32");
Referring to of dll the external memory generates this violation by VC6
specification.
I considered whether the whole should have been converted into winsock2.
However, Now, DLL of MinGW creation operates wonderfully as it is.
That's right, it has pliability by replacement of simple DLL.
Then, I propose the system using winsock(non IPV6) in construction of
VC6.
Hiroshi Saito
2005-12-08 18:52:11 +01:00
|
|
|
#endif
|
2005-08-25 19:51:01 +02:00
|
|
|
#define EAI_AGAIN WSATRY_AGAIN
|
|
|
|
|
#define EAI_BADFLAGS WSAEINVAL
|
|
|
|
|
#define EAI_FAIL WSANO_RECOVERY
|
|
|
|
|
#define EAI_FAMILY WSAEAFNOSUPPORT
|
|
|
|
|
#define EAI_MEMORY WSA_NOT_ENOUGH_MEMORY
|
|
|
|
|
#define EAI_NODATA WSANO_DATA
|
|
|
|
|
#define EAI_NONAME WSAHOST_NOT_FOUND
|
|
|
|
|
#define EAI_SERVICE WSATYPE_NOT_FOUND
|
2005-10-15 04:49:52 +02:00
|
|
|
#define EAI_SOCKTYPE WSAESOCKTNOSUPPORT
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* !WIN32 */
|
|
|
|
|
#endif /* !EAI_FAIL */
|
2003-08-07 18:45:21 +02:00
|
|
|
|
|
|
|
|
#ifndef AI_PASSIVE
|
2003-03-29 12:31:52 +01:00
|
|
|
#define AI_PASSIVE 0x0001
|
2003-08-07 18:45:21 +02:00
|
|
|
#endif
|
2003-08-14 20:32:55 +02:00
|
|
|
|
2003-08-07 18:45:21 +02:00
|
|
|
#ifndef AI_NUMERICHOST
|
2003-08-14 20:32:55 +02:00
|
|
|
/*
|
|
|
|
|
* some platforms don't support AI_NUMERICHOST; define as zero if using
|
|
|
|
|
* the system version of getaddrinfo...
|
|
|
|
|
*/
|
|
|
|
|
#if defined(HAVE_STRUCT_ADDRINFO) && defined(HAVE_GETADDRINFO)
|
|
|
|
|
#define AI_NUMERICHOST 0
|
|
|
|
|
#else
|
2003-03-29 12:31:52 +01:00
|
|
|
#define AI_NUMERICHOST 0x0004
|
2003-08-07 18:45:21 +02:00
|
|
|
#endif
|
2003-08-14 20:32:55 +02:00
|
|
|
#endif
|
2003-03-29 12:31:52 +01:00
|
|
|
|
2003-08-07 18:45:21 +02:00
|
|
|
#ifndef NI_NUMERICHOST
|
2003-06-12 09:36:51 +02:00
|
|
|
#define NI_NUMERICHOST 1
|
2003-08-07 18:45:21 +02:00
|
|
|
#endif
|
|
|
|
|
#ifndef NI_NUMERICSERV
|
2003-06-12 09:36:51 +02:00
|
|
|
#define NI_NUMERICSERV 2
|
2003-08-07 18:45:21 +02:00
|
|
|
#endif
|
Fix assorted issues in client host name lookup.
The code for matching clients to pg_hba.conf lines that specify host names
(instead of IP address ranges) failed to complain if reverse DNS lookup
failed; instead it silently didn't match, so that you might end up getting
a surprising "no pg_hba.conf entry for ..." error, as seen in bug #9518
from Mike Blackwell. Since we don't want to make this a fatal error in
situations where pg_hba.conf contains a mixture of host names and IP
addresses (clients matching one of the numeric entries should not have to
have rDNS data), remember the lookup failure and mention it as DETAIL if
we get to "no pg_hba.conf entry". Apply the same approach to forward-DNS
lookup failures, too, rather than treating them as immediate hard errors.
Along the way, fix a couple of bugs that prevented us from detecting an
rDNS lookup error reliably, and make sure that we make only one rDNS lookup
attempt; formerly, if the lookup attempt failed, the code would try again
for each host name entry in pg_hba.conf. Since more or less the whole
point of this design is to ensure there's only one lookup attempt not one
per entry, the latter point represents a performance bug that seems
sufficient justification for back-patching.
Also, adjust src/port/getaddrinfo.c so that it plays as well as it can
with this code. Which is not all that well, since it does not have actual
support for rDNS lookup, but at least it should return the expected (and
required by spec) error codes so that the main code correctly perceives the
lack of functionality as a lookup failure. It's unlikely that PG is still
being used in production on any machines that require our getaddrinfo.c,
so I'm not excited about working harder than this.
To keep the code in the various branches similar, this includes
back-patching commits c424d0d1052cb4053c8712ac44123f9b9a9aa3f2 and
1997f34db4687e671690ed054c8f30bb501b1168 into 9.2 and earlier.
Back-patch to 9.1 where the facility for hostnames in pg_hba.conf was
introduced.
2014-04-02 23:11:24 +02:00
|
|
|
#ifndef NI_NAMEREQD
|
|
|
|
|
#define NI_NAMEREQD 4
|
|
|
|
|
#endif
|
2003-06-12 09:36:51 +02:00
|
|
|
|
2003-08-04 02:43:34 +02:00
|
|
|
#ifndef NI_MAXHOST
|
2003-06-12 09:36:51 +02:00
|
|
|
#define NI_MAXHOST 1025
|
2003-08-07 18:45:21 +02:00
|
|
|
#endif
|
|
|
|
|
#ifndef NI_MAXSERV
|
2003-06-12 09:36:51 +02:00
|
|
|
#define NI_MAXSERV 32
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
2003-08-07 18:45:21 +02:00
|
|
|
#ifndef HAVE_STRUCT_ADDRINFO
|
|
|
|
|
|
2006-07-06 04:12:32 +02:00
|
|
|
#ifndef WIN32
|
2003-08-07 18:45:21 +02:00
|
|
|
struct addrinfo
|
|
|
|
|
{
|
|
|
|
|
int ai_flags;
|
|
|
|
|
int ai_family;
|
|
|
|
|
int ai_socktype;
|
|
|
|
|
int ai_protocol;
|
|
|
|
|
size_t ai_addrlen;
|
|
|
|
|
struct sockaddr *ai_addr;
|
|
|
|
|
char *ai_canonname;
|
|
|
|
|
struct addrinfo *ai_next;
|
|
|
|
|
};
|
2006-07-06 04:12:32 +02:00
|
|
|
#else
|
|
|
|
|
/*
|
|
|
|
|
* The order of the structure elements on Win32 doesn't match the
|
|
|
|
|
* order specified in the standard, but we have to match it for
|
|
|
|
|
* IPv6 to work.
|
|
|
|
|
*/
|
|
|
|
|
struct addrinfo
|
|
|
|
|
{
|
|
|
|
|
int ai_flags;
|
|
|
|
|
int ai_family;
|
|
|
|
|
int ai_socktype;
|
|
|
|
|
int ai_protocol;
|
|
|
|
|
size_t ai_addrlen;
|
|
|
|
|
char *ai_canonname;
|
|
|
|
|
struct sockaddr *ai_addr;
|
|
|
|
|
struct addrinfo *ai_next;
|
|
|
|
|
};
|
|
|
|
|
#endif
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* HAVE_STRUCT_ADDRINFO */
|
2003-08-07 18:45:21 +02:00
|
|
|
|
2003-04-02 02:49:28 +02:00
|
|
|
|
|
|
|
|
#ifndef HAVE_GETADDRINFO
|
|
|
|
|
|
|
|
|
|
/* Rename private copies per comments above */
|
|
|
|
|
#ifdef getaddrinfo
|
|
|
|
|
#undef getaddrinfo
|
|
|
|
|
#endif
|
|
|
|
|
#define getaddrinfo pg_getaddrinfo
|
|
|
|
|
|
|
|
|
|
#ifdef freeaddrinfo
|
|
|
|
|
#undef freeaddrinfo
|
|
|
|
|
#endif
|
|
|
|
|
#define freeaddrinfo pg_freeaddrinfo
|
|
|
|
|
|
|
|
|
|
#ifdef gai_strerror
|
|
|
|
|
#undef gai_strerror
|
|
|
|
|
#endif
|
|
|
|
|
#define gai_strerror pg_gai_strerror
|
|
|
|
|
|
2003-06-12 09:36:51 +02:00
|
|
|
#ifdef getnameinfo
|
|
|
|
|
#undef getnameinfo
|
|
|
|
|
#endif
|
2003-08-04 02:43:34 +02:00
|
|
|
#define getnameinfo pg_getnameinfo
|
2003-06-12 09:36:51 +02:00
|
|
|
|
2019-05-22 19:04:48 +02:00
|
|
|
extern int getaddrinfo(const char *node, const char *service,
|
|
|
|
|
const struct addrinfo *hints, struct addrinfo **res);
|
2017-06-21 20:39:04 +02:00
|
|
|
extern void freeaddrinfo(struct addrinfo *res);
|
2003-04-02 02:49:28 +02:00
|
|
|
extern const char *gai_strerror(int errcode);
|
2019-05-22 19:04:48 +02:00
|
|
|
extern int getnameinfo(const struct sockaddr *sa, int salen,
|
|
|
|
|
char *node, int nodelen,
|
|
|
|
|
char *service, int servicelen, int flags);
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* HAVE_GETADDRINFO */
|
2003-04-02 02:49:28 +02:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* GETADDRINFO_H */
|
