[PATCH] Fix broken mlock detection

Johannes Schindelin Johannes.Schindelin at gmx.de
Thu Jun 17 14:13:25 CEST 2021

Hi Werner,

On Wed, 16 Jun 2021, Werner Koch wrote:

> On Wed, 16 Jun 2021 10:07, Johannes Schindelin said:
> > Which means that we are not at all detecting whether `mlock()` is
> > broken.
> Thanks for your correct analysis.  I wrote this test code 23 years ago
> and this is the first report.  Seems that until now this has never been
> tried on systems which allocate memory above 2 GiB.

Right. 23 years ago, some people still believed that nobody will ever need
more than 640 kilobyte of RAM ;-)

BTW I _suspect_ that the reason I ran into this is a recent change in
Cygwin and/or Windows 10. I cannot recall seeing `malloc()`ed blocks above

> > This actually happened here, in the i686 MSYS2 build of libgcrypt.
> Please take care: I would not suggest to build the Windows version with
> MSYS - the only supported toolchain for Windows is gcc.

Oh, I should have been clearer: I _am_ building using GCC.

MSYS2 is based partially on Cygwin (the MSYS2 runtime is a close fork of
the Cygwin runtime, to provide a POSIX emulation layer), and partially on
ArchLinux (from where it inherits its package management system, pacman).

It is a well-tested system, and it is used as an important block of Git
for Windows: millions of users already rely on it for over five years.

In other words: I am not worried about building and using GNU Privacy
Guard and libgcrypt in MSYS2's context ;-)

> > we only need the remainder modulo the page size (which is a power of
> > two) anyway, it does not matter whether we clip, say, a 64-bit `size_t`
> > to a 32-bit `unsigned long`. It does matter, though, whether we
> Yep.  I would anyway use size_t here to avoid questions about the
> reasoning.  In fact secmem.c uses uintptr_t but that is a bit too
> complicated to use in this configure test.

As long as you can be sure that the type that is used is actually defined,
I do not care which one you use. I used `unsigned long` because there is
no question that it is defined here, whereas I have run into compile
problems in the past on systems where `size_t` was not defined.


More information about the Gcrypt-devel mailing list