[PATCH] [W32] Use SSIZE_T for ssize_t on Windows instead of long

[John Thacker]

On Wed, May 20, 2026, 9:42 PM NIIBE Yutaka via Gcrypt-devel <
gcrypt-devel at gnupg.org> wrote:

> Werner Koch wrote:
> > Other opinions?
>
> I think that it's consisitent to use SSIZE_T.  It's better to change.
>
> On the other hand, we know that MSVC compiles some code differently
> (than developers expect).  I have experiences to examine constant-time
> intended code compiled by MSVC, using godbolt.org.  I wonder (and am not
> sure) if our libgcrypt is OK when building with MSVC.
>

Libgcrypt does not build with MSVC. What you can do, and Wireshark does, is
build with MSYS2/MingW, which defines ssize_t as 64-bit on Win64 and 32-bit
on Win32. The resultant DLL can be linked into a program when the rest of
the executable and libraries are built with MSVC, and use the gcrypt.h
header for necessary includes.

However, this doesn't work without this patch on Win64, because the MSYS2
built DLL uses 64-bit ssize_t but MSVC will typedef ssize_t as a 32-bit
long, so gcrypt.h is ABI incompatible with the built DLL. If the header
typedef is patched like this, then it all works. That's even aside from the
issue that Wireshark uses ssize_t in our own API.

So I would say this is not an ABI break at all, but an ABI repair that
makes it more consistent. I think it's still not possible to build the
entire library with MSVC, but it at least makes it possible to use an
unpatched gcrypt.h with a library cross compiled for Win64.

Thanks,
John Thacker

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20260521/0fcfa408/attachment.html>