Re: macos ventura SDK spews warnings
| От | Tom Lane |
|---|---|
| Тема | Re: macos ventura SDK spews warnings |
| Дата | |
| Msg-id | 1809538.1665941733@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: macos ventura SDK spews warnings (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: macos ventura SDK spews warnings
|
| Список | pgsql-hackers |
I wrote:
> So I pushed (1), but on the way to testing (2), I discovered a totally
> independent problem with the 13.0 SDK in older branches:
> In file included from ../../../src/include/postgres.h:46:
> In file included from ../../../src/include/c.h:1387:
> In file included from ../../../src/include/port.h:17:
> In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/netdb.h:91:
> In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/netinet/in.h:81:
> /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/socket.h:471:1: error: expected ';' after top
leveldeclarator
> __CCT_DECLARE_CONSTRAINED_PTR_TYPES(struct sockaddr_storage, sockaddr_storage);
> ^
Ah, I see it. This is not failing everywhere, only in gram.y and
associated files, and it happens because those have a #define for REF,
which is breaking this constrained_ctypes stuff:
/Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/socket.h:471:1: error: expected ';' after top
leveldeclarator
__CCT_DECLARE_CONSTRAINED_PTR_TYPES(struct sockaddr_storage, sockaddr_storage);
^
/Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/constrained_ctypes.h:588:101: note: expanded
frommacro '__CCT_DECLARE_CONSTRAINED_PTR_TYPES'
__CCT_DECLARE_CONSTRAINED_PTR_TYPE(basetype, basetag, REF); \
^
Now on the one hand Apple is pretty clearly violating user namespace
by using a name like "REF", and I'll go file a bug about that.
On the other hand, #defining something like "REF" isn't very bright
on our part either. We usually write something like REF_P when
there is a danger of parser tokens colliding with other names.
I think the correct, future-proof fix is to s/REF/REF_P/ in the
grammar. We'll have to back-patch that, too, unless we want to
change what port.h includes. I found that an alternative possible
band-aid is to do this in port.h:
diff --git a/src/include/port.h b/src/include/port.h
index b405d0e740..416428a0d2 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -14,7 +14,6 @@
#define PG_PORT_H
#include <ctype.h>
-#include <netdb.h>
#include <pwd.h>
/*
@@ -491,6 +490,8 @@ extern int pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
size_t buflen, struct passwd **result);
#endif
+struct hostent; /* avoid including <netdb.h> here */
+
extern int pqGethostbyname(const char *name,
struct hostent *resultbuf,
char *buffer, size_t buflen,
but it seems like there's a nonzero risk that some third-party
code somewhere is depending on our having included <netdb.h> here.
So ceasing to do that in the back branches doesn't seem great.
Changing a parser token name in the back branches isn't ideal
either, but it seems less risky to me than removing a globally
visible #include.
regards, tom lane
В списке pgsql-hackers по дате отправления: