If we can assume C99, we have the type.
I know, it is not guaranteed to be enough size. For particular host (Windows 64-bit), it works.

Here are warnings:

../../../libgpg-error/src/spawn-w32.c: In function 'do_create_pipe_and_estream':
../../../libgpg-error/src/spawn-w32.c:65:27: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 #define handle_to_fd(a)  ((int)(a))

../../../libgpg-error/src/spawn-w32.c: In function '_gpgrt_spawn_process_fd':
../../../libgpg-error/src/spawn-w32.c:67:27: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 #define handle_to_pid(a) ((int)(a))
                           ^

../../../libgpg-error/src/estream.c: In function 'func_fd_read':
../../../libgpg-error/src/estream.c:155:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
 # define IS_INVALID_FD(a)    ((void*)(a) == (void*)(-1)) /* ?? FIXME.  */
                               ^

Using intptr_t works with this particular case but it does not
solve the general problem under Windows. On Windows an integer
may identify a libc file handle, a socket, and some other
objects. Despite that they are integers they are all different objects
and it is hard to distinguish them

Mixing handles and libc integers is even worse. My long term
plan is to move move all things to gpgrt and use a syshd based
estream_t instead. This allows us to keep track of the object
type at one place.

or pid_t the casting we use in libassuan was the cause for that
subtle bug we fixed last week only. The problem here is that
Windows can use a pid_t and a handle to describe a process. They
are not compatible.

Using intptr_t will also defeat the use of atoi() and the
translate file handle stuff we use at several places.

I would say better live with the warnings than to hide these
problems.