npth_connect and npth_accept should deprecated (since it's not consistent with 64-bit Windows). In gnupg master, there is no use.

In libassuan 3.0, we distinguish the integer identifier for process and the HANDLE (by T6487).
This was problem was solved.

assuan_sock_accept approach is taken in gnupg master.

gniibe/t6606 patches are all pushed into master.

Applied: rGb8c5d99406c9: gpg,agent,kbx,sm,scd,tpm2d,g13: Use assuan_control.

In T6606#173044, @gniibe wrote:

More care is needed to be perfect; There are places in GnuPG where assuan_sock_connect may be used before syscall clamp set up (after the first assuan_sock_bind failure).

I pushed the commit: rE64532db11fcd: build: New configure option --with-libtool-modification.

Pushed the change to libgpg-error.

I learned that AC_CONFIG_COMMANDS macro can be used to improve the case of config.status.

How about the change like:

Applied to master.

Applied to 2.4.

Applied to master.

Applied the changes for libassuan T6487 into gniibe/t6606.

Merged to master (to be 3.0.0).

Pushed the change in gniibe/t6606 branch.

Another approach would be:

• Use assuan_sock_accept which has consistent API with gnupg_fd_t

Fixed in: rP66abf7cb1e1b: Update GPL2 for new FSF address. Use URL for license.

On 64-bit Windows, the situation now is:

Use of FD2INT for the first argument of select is semantically not good. It's the number of file descriptor. When we use FD2INT here, the type is converted to 64-bit integer, then implicitly demoted to 32-bit integer. We need new macro, say, FD2NUM to convert FD into 32-bit integer.
<--- done in: rGea1935252e28: commond: Introduce FD2NUM to express conversion to number of fds.

Here is a test program for 64-bit Windows to see how cast works:

#include <stdint.h>
#include <stdio.h>

Update the patch to allow --compatibility-flags hashing-in-parallel.