[PATCH] Fix broken mlock detection
Johannes.Schindelin at gmx.de
Thu Jun 17 14:13:25 CEST 2021
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