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.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T6508 Port GnuPG to 64-bit Windows | ||
| Testing | • gniibe | T4655 Windows 64-bit: gnupg_fd_t, assuan_fd_t and int for fd in the API, and casts | ||
| Resolved | • gniibe | T6236 libassuan: Support sendfd/recvfd (possibly by new API) on Windows |
HANDLE type casting to long is wrong (it results masking the value to 32-bit, which is not needed).
I fixed:
API which uses int for fd:
GnuPG common:
gpgrt:
... which are all valid and useful. But, for me, it was confusing.
I'm confusing if following API should use gnupg_fd_t or not:
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.
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:
For libassuan:
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.