Re: macos ventura SDK spews warnings - Mailing list pgsql-hackers

From Tom Lane
Subject Re: macos ventura SDK spews warnings
Date
Msg-id 1809538.1665941733@sss.pgh.pa.us
Whole thread Raw
In response to Re: macos ventura SDK spews warnings  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: macos ventura SDK spews warnings  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: macos ventura SDK spews warnings
Next
From: Matthias van de Meent
Date:
Subject: Re: PATCH: Using BRIN indexes for sorted output