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

Description

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.

gniibe created this task.Jul 25 2019, 2:33 AM

API which uses int for fd:
GnuPG common:

  • gnupg_create_pipe, gnupg_create_outbound_pipe, gnupg_create_inbound_pipe
  • gnupg_spawn_process_fd

gpgrt:

  • 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)Jul 25 2019, 3:45 AM
gniibe updated the task description. (Show Details)
gniibe updated the task description. (Show Details)Jul 25 2019, 6:25 AM

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 ?
gniibe claimed this task.Jul 25 2019, 8:25 AM

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.

werner added a subscriber: werner.Jul 31 2019, 8:52 AM

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.