May 28 2013
May 24 2013
Aug 9 2012
Inline is an extension to C90 implemented by almost all compilers.
What we do is what the gcc manual suggest for ages:
This combination of `inline' and `extern' has almost the effect of a macro. The way to use it is to put a function definition in a header file with these keywords, and put another copy of the definition (lacking `inline' and `extern') in a library file. The definition in the header file will cause most calls to the function to be inlined. If any uses of the function remain, they will refer to the single copy in the library.
I don’t know why clang seems to be the only compiler who does not grok
this. Libgcrypt has been compiled on a wide range of compilers
without any problem.
Wait, I see. Clang pretends to be gcc and defines GNUC. Thus
mpi-internal.h includes the inline functions:
#ifdef __GNUC__ #include "mpi-inline.h" #endif
which is a valid gcc construct. As with some other bug reports; I can
only suggest to fix clang and don't have it define GNUC .
Jun 13 2012
It seems that my patch does actually break gcc... i'm not sure how to handle
this correctly anyway. It seems that the problem is actually unsolvable, and
there's no correct way to mix inline functions and external assembly definitions.
Sep 27 2011
please explain why this is a problem
Sep 25 2011
May 12 2011
Fixed today, thanks.
Sep 22 2010
Fixed in my working copies. Thanks.
Sep 20 2010
Feb 11 2010
Marcus, plase have a look at it.
Feb 10 2010
Dec 16 2009
I've tried to reproduce the fault with 1.2.0 but could not so it seems to be
I think that this is probably fixed in the gpgme 1.2.0 release. The following
patch by Werner has a similar effect to the patch provided by the submitter:
Dec 11 2009
will be in 1.4.5 to be released in a few minutes.
Dec 10 2009
Okay, for the development version I implemented a configure option
This is in the SVN trunk, rev 1415.
I believe that is the least intrusive change. Is it important for you; thus
shall I backport it to 1.4.5 which will be released in a few days?
Dec 2 2009
Aihhh. The failure mode depends on the malloc implementation. We are only
shrinking memory and thus some implementations simply return the same pointer.
Obviously not in BSD.
Nov 11 2009
Is there any chance of getting this fixed? The problem is very annoying as it
causes the library to disturb the application using it and I can't think of any
simple workaround for it.
The patch is just three lines so it should be easy to include, right?
Aug 28 2009
Marcus: I recall that you recently changed something in the cancel code - is
that his problem?
Aug 26 2009
Feb 3 2009
Is it possible to match at most one occurrence of a pattern without the "-r"
option? ("extended regular expression", a GNU extension unfortunately)
Sure, you are right. OTOH this code is in use by gnupg and libgcrypt for many
years without problems (twofish.c used similar code).
Feb 2 2009
Hmm - I can't explain why this would have affected 1.4.4 but not 1.4.3, but that
is my experience.
In general we try to avoid direct tests for OS features but use configure tests.
However in this case it is simpler to always include sys/time.h. This is
harmless because gcrypt.h does it also unconditionally.
I don't think that it is a regression in Libgcrypt because the problematic rule
was not changed. Did you change the CFLAGS passed to configure?
Feb 1 2009
Dec 9 2008
Dec 8 2008
Trivial patch. Closing bug,.
Oct 20 2008
Applied to trunk. Unfortunately it didn't made it into 1.1.7.
Oct 13 2008
Changed in GnuPG trunk 4849.
Oct 10 2008
Nov 19 2007
Fixed in SVN. Updated all translations.
Also fixed in 2.0.x, though not yet commited.
Nov 18 2007
Jul 25 2007
Apr 16 2007
Available in 1.4.7
Feb 26 2007
Implemented for gpg2 (SVN). Will also be backported to gpg1 for 1.4.7.