Page MenuHome GnuPG

Windows 64-bit: gnupg_fd_t, assuan_fd_t and int for fd in the API, and casts
Testing, WishlistPublic


This entry is basically my memorandum so that I won't make mistake.

We have type gnupg_fd_t, assuan_fd_t to represent file descriptor of POSIX or HANDLE of Windows.

On 32-bit machine, HANDLE can be represented by int, so, no problem.

On 64-bit machine, it's intptr_t as integer type to represent HANDLE.

For now, it works (as long as the value of HANDLE is small enough), but there are places where we need fix.

Event Timeline

API which uses int for fd:
GnuPG common:

  • gnupg_create_pipe, gnupg_create_outbound_pipe, gnupg_create_inbound_pipe
  • gnupg_spawn_process_fd


  • gpgrt_make_pipe (not yet exposed to public API)
  • gpgrt_spawn_process_fd (not yet exposed to public API)

... which are all valid and useful. But, for me, it was confusing.

gniibe updated the task description. (Show Details)

I'm confusing if following API should use gnupg_fd_t or not:

  • iobuf_fdopen, iobuf_fdopen_nc
    • Perhaps, these are using int for fd, like es_fdopen
  • set_attrib_fd ?
  • read_passphrase_from_fd ?
  • set_status_fd ?
  • is_secured_file ?

I was afraid that there are wrong usage where HANDLE is passed where int for fd is expected (or opposite).
But it seems, there are only usage where it should be gnupg_fd_t ideally but using int.

Actually all this code shall be replaced by new code from gpgrt. Most likely using estream_t for all of them.

werner triaged this task as Wishlist priority.Jul 31 2019, 12:42 PM
werner added a project: Memo.

SOCKET handle is UINT_PTR on Windows. It is u_int on original MinGW, it is UINT_PTR (and unsinged __int64_t) on MinGW-W64.

We need to reconsider the API (and ABI) when we port it on 64-bit machine, although it will keep working with int (as long as Microsoft keeps its value within the range of 32-bit).

For npth:

  • npth_connect
  • npth_accept
  • member of fd_set in use by npth_select

For libassuan:

  • assuan_socket
  • assuan_connect
  • API-wise it's OK: assuan_socketpair returns assuan_fd_t, but not implemented (yet). Same for assuan_sendmsg, assuan_recvmsg.
  • assuan_socket_connect_fd should not be available on Windows, as there is no case which can be used.
gniibe changed the task status from Open to Testing.Aug 4 2023, 2:51 AM

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

For assuan, we fixed:

AFAIK, there is no remaining issues.