Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Cleaning up historical portability baggage
Date
Msg-id 20220825194729.5cgvx26ekbtmvjzg@awork3.anarazel.de
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Cleaning up historical portability baggage
List pgsql-hackers
Hi,

On 2022-08-18 18:13:38 +1200, Thomas Munro wrote:
> Here's a slightly better AF_INET6 one.  I'm planning to push it
> tomorrow if there are no objections.

You didn't yet, I think. Any chance you could? The HAVE_IPV6 stuff is
wrong/ugly in the meson build, right now, and I'd rather not spend time fixing
it up ;)


> It does something a little more aggressive than the preceding stuff, because
> SUSv3 says that IPv6 is an "option".  I don't see that as an issue: it also
> says that various other ubiquitous stuff we're using is optional.  Of
> course, it would be absurd for a new socket implementation to appear today
> that can't talk to a decent chunk of the internet, and all we require here
> is the headers.  That optionality was relevant for the transition period a
> couple of decades ago.

> From f162a15a6d723f8c94d9daa6236149e1f39b0d9a Mon Sep 17 00:00:00 2001
> From: Thomas Munro <tmunro@postgresql.org>
> Date: Thu, 18 Aug 2022 11:55:10 +1200
> Subject: [PATCH] Remove configure probe for sockaddr_in6 and require AF_INET6.
> 
> SUSv3 <netinet/in.h> defines struct sockaddr_in6, and all targeted Unix
> systems have it.  Windows has it in <ws2ipdef.h>.  Remove the configure
> probe, the macro and a small amount of dead code.
> 
> Also remove a mention of IPv6-less builds from the documentation, since
> there aren't any.
> 
> This is similar to commits f5580882 and 077bf2f2 for Unix sockets.
> Even though AF_INET6 is an "optional" component of SUSv3, there are no
> known modern operating system without it, and it seems even less likely
> to be omitted from future systems than AF_UNIX.
> 
> Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com

Looks good to me.


I'm idly wondering whether it's worth at some point to introduce a configure
test of just compiling a file referencing all the headers and symbols we exist
to be there...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: postgres_fdw hint messages
Next
From: Tom Lane
Date:
Subject: Re: pg_regress: lookup shellprog in $PATH