Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mlahZ-0007cp-3H for pgsql-committers@arkaria.postgresql.org; Fri, 12 Nov 2021 17:51:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mlahX-0007mo-D4 for pgsql-committers@arkaria.postgresql.org; Fri, 12 Nov 2021 17:50:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mlahX-0007mf-5t for pgsql-committers@lists.postgresql.org; Fri, 12 Nov 2021 17:50:59 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mlahU-0004Uo-6D for pgsql-committers@lists.postgresql.org; Fri, 12 Nov 2021 17:50:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1ACHorkq1731093; Fri, 12 Nov 2021 12:50:53 -0500 From: Tom Lane To: Peter Eisentraut cc: pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Remove check for accept() argument types In-reply-to: <1683239.1636726865@sss.pgh.pa.us> References: <1440792.1636558888@sss.pgh.pa.us> <3863895c-d40b-4154-de8f-4961386b2515@enterprisedb.com> <1683239.1636726865@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 12 Nov 2021 09:21:05 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1731091.1636739453.1@sss.pgh.pa.us> Date: Fri, 12 Nov 2021 12:50:53 -0500 Message-ID: <1731092.1636739453@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Peter Eisentraut writes: >> What does the man page say the correct type >> would be? size_t? > The machine's not booted up right now :-(. But I'm pretty sure we > shouldn't consider using size_t here, as it's not real clear that that > couldn't be 64 bits on any affected platforms. Your previous research > said that the desired type is 32 bits on all such platforms, so I think > that "int" is correct; we need only debate signedness. Hmm ... now that I'm in my office, I checked this and HPUX 10.20's accept(2) man page saith SYNOPSIS #include AF_CCITT only #include int accept(int s, void *addr, int *addrlen); _XOPEN_SOURCE_EXTENDED only int accept(int s, struct sockaddr *addr, size_t *addrlen); gaur is using -D_XOPEN_SOURCE_EXTENDED and hence building against the latter definition. (I found out quite a long time ago that without _XOPEN_SOURCE_EXTENDED, this platform has a LOT of discrepancies from SUS v2.) Further down, there's FUTURE DIRECTION The default behavior in this release is still the classic HP-UX BSD Sockets, however it will be changed to X/Open Sockets in some future release. At that time, any HP-UX BSD Sockets behavior which is incompatible with X/Open Sockets may be obsoleted. HP customers are advised to migrate their applications to conform to X/Open specification (see xopen_networking(7)). So what it looks like to me is (1) Original BSD Sockets defined the argument as "int *addrlen". (I confirmed this by looking in an ancient copy of Stevens' Unix Network Programming.) (2) X/Open thought it'd be better to use size_t. (3) POSIX decided to resolve the conflict by inventing socklen_t. However, SUS v2 says specifically that socklen_t "is an unsigned opaque integral type of length of at least 32 bits". The "unsigned" part was removed in later POSIX editions, which surprises me --- they don't usually change the standard in the direction of less definiteness. On the whole, I still think "unsigned int" is our best compromise. But maybe we should use size_t and cite X/Open as authority. regards, tom lane