Re: macos ventura SDK spews warnings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: macos ventura SDK spews warnings
Date: 2022-10-16 17:35:33
Message-ID: 1809538.1665941733@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 level declarator
> __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 level declarator
__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 from macro '__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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2022-10-16 18:22:01 Re: PATCH: Using BRIN indexes for sorted output
Previous Message Tom Lane 2022-10-16 16:40:11 Re: macos ventura SDK spews warnings