[git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-35-gcfc151b

[Werner Koch]

On Fri, 17 Jan 2014 12:36, dbaryshkov at gmail.com said:

> into generated gpg-error.h header file? It would be platform
> dependent, of course,

Right and that is what needs to be avoided.  gpgrt shall replace
platform dependent code in Libgcrypt, GPGME, and GnuPG.  It makes more
sense to do have the platform dependent code at just one place.  In
particular a future 64 bit Windows implementation of GnuPG will need it
(e.g. sizeof(HANDLE) > sizeof(int))

> but existing 'dumped' mutexes also look platform dependent (and very fragile).

I can't see how this is fragile.  Alignment requirements?  The test case
should exhibity this soon.

Not exposing the internals also allows to change the internal
implementation; for example from the fork problematic pthread mutexes to
the cleaner semaphores.

> E.g. in it's current state gpg-error.h is definitely not multi-platform safe.

As with several other header files, they are platform dependent.  We
can't use configure macros in a public header.

> And last BTW: if you care about ABI, most probably '_vers' field should be moved
> to the beginning of the gpgrt_lock_t structure - thus it can be safely

Breaks alignment requirements.  Thus it is easier to move it to the end.
Okay, I could add another union or swap the union and the struct.  Is it
worth the trouble?

> And one would probably need the 'mutex type' magic value - because
> otherwise one can (theoretically) build gpg-error library with posix header
> for win32 and this will be unnoticed (if _vers fields fall to the same place).

That has always been the case.  The configure macro actually prints a
warning if you use a wrong one.

Thanks for the comments.  I'll change the build systems to allow the
inclusion of pre-generated lock objects for cross-compiling.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.