I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

You can test with newer compiler.

It looks like the recipe to build the source file is missing the necessary arch options. I.e., -mcpu=power7 -mvsx ...

I can't reproduce the error (no problem for build). My (cross-)compiler is:

There is nothing spiteful about this other than your actions.

werner closed this task as Spite.

We do not use Github.

Also see Issue #10, Add Travis testing in the GnuPG GitHub. The PR adds Travis testing to the entire GnuPG suite.

In case of gcc 4.8 on Solaris, could you please try this patch (instead of configure patch) to see if it works?

rG5b22d2c4008 tested good under Asan.

I was talking to Thomas Dickey, who maintains Ncurses. Ncurses had a leak and he offered a config option to remove it. Ncurses config responds to --disable-leaks.

Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

I'm going to bring newest m4/iconv.m4 from original (gettext), which apparently fixed file descriptor leaks.

An FYI... Once we cleared the earlier findings GnuPG tested OK under Asan. GnuPG itself had no findings, and it did not cause any dependent libraries to generate findings.

This patch tested OK.

The second and third arguments passed to xgcry_control seem to be lost when calling gcry_control.

Here are the next two failures I am seeing while testing libgrcypt. It appears to be related to GCRYCTL_INIT_SECMEM.

I'm still seeing a few odd outputs from make check, but I have not investigated them yet.

Maybe cleaner option for mpi/mpiutil.c would be to statically allocate the constants

Here's a couple of awful hacks that get me through make check. Feel free to restate how awful they are; I know it is a bad thing to do.

It looks like this patch clears this finding:

It looks like this patch clears this finding:

It looks like Solaris only needs CFLAGS+=-std=c99. It was added for all programs and libraries listed at https://www.gnupg.org/download/index.html.

Similar issue with ntbtls:

Libassuan 2.5.3 has a similar problem:

Here's the patch:

Werner Koch <wk@gnupg.org> added the comment:

Please show me the disassembly of an example along with the commands and program
versions you used to create an object file with removed wipememory code.

volatile is used to make sure the writes actually hit the
memory. gcc is not allowed to remove that for the simple reason, it
can't know whether this plain RAM or a device mapped into the address
space. That is the whole point of using volatile and it has been
introduced back in the 80ies for just this reason (back than to write
to video memory).

One relatively unimportant misunderstanding is due to the fact that
the standard only talks about accesses to volatile objects. It does
not talk about accesses via volatile qualified pointers. Some
programmers believe that using a pointer-to-volatile should be
handled as though it pointed to a volatile object. That is not
guaranteed by the standard and is therefore not portable. However,
this is relatively unimportant because gcc does in fact treat a
pointer-to-volatile as though it pointed to a volatile object.

It says that it's not guaranteed and it's not portable by the C
language itself.

So, you are right that volatile qualifier to a pointer should be
avoided (from viewpoint of portability).

I think that I am also right that it works with GCC implementation
(in 2008, at least).

I'm actually more concerned that the optimizer will remove the code
because it surmises its a dead store. That's the issue I am trying to
articulate.

You shouldn't use volatile for that when compiling with GCC.

Any references which support this opinion of yours, please?

On Tue, Jun 16, 2015 at 4:31 AM, NIIBE Yutaka via BTS
<gnupg@bugs.g10code.com> wrote:

NIIBE Yutaka <gniibe@fsij.org> added the comment:

I think that JW had some confusion. I believe that his argument is irrelevant
for libgcrypt's implementation of wipememory.

Changed status to 'unread'. I'm not chatting.

I was able to duplicate Bug 1862: Building static GnuPG 2.1.2 fails due to
multiply defined symbols.

/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:46:
multiple definition of `gpg_err_code_from_errno'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:137:
first defined here
/home/jwalton/gpg-analyze/lib/libgpg-error.a(libgpg_error_la-visibility.o): In
function `gpg_err_code_from_syserror':
/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:58:
multiple definition of `gpg_err_code_from_syserror'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:151:
first defined here
collect2: error: ld returned 1 exit status
make[3]: * [t-stringhelp] Error 1
make[3]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory `/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2'
make: * [all] Error 2

LIBRARY=gnupg
VERSION=2.1.2
FILE="$LIBRARY-$VERSION"

export PREFIX=/usr/local

cd "$FILE"
./configure --enable-static --disable-shared
--with-libgpg-error-prefix="$PREFIX" --with-libassuan-prefix="$PREFIX"
--with-ksba-prefix="$PREFIX" --with-npth-prefix="$PREFIX"
--with-libgcrypt-prefix="$PREFIX" --prefix="$PREFIX"

make

Changed status to 'unread'. I am not chatting.

Also see "Is a misaligned load due to a cast undefined behavior?"
(http://stackoverflow.com/q/28893303) on Stack Overflow.

I wanted to verify it was in fact undefined behavior.