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

[Werner Koch]

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

> I fully understand and support your idea of handling platform-dependent code
> in one place. I suggest to have a platform-independent API, but with platform
> dependent ABI. Applications using gpgrt won't be caring about exact

An ABI is always platform dependent.  

> of gpgrt_lock_t (or GPGRT_LOCK_INITIALIZER). They should use those identifiers
> in the program code as black boxes.

Right.  That is the case. 

>> I can't see how this is fragile.  Alignment requirements?  The test case
>> should exhibity this soon.
>
> Alignment, contents, libc/libpthread versioning, etc.

If you change the ABI of a platform you can't expect that any old binary
continues to work.  Thus libc or libpthread are not a problem.  I don't
know what you mean by content - if you mean the static mutex
initializer, this is part of the ABI.  Alignment: well, there is no
fully portable solution.

> Even if we put exact implementation to the header, we still can change
> it later - provided we have proper structure versioning. You did
> this in the past with thread CBS structure, so I see no problem with that.

Al kind of mess may happen if you include pthreads.h in a header used by
a program which does not use threads.  Thus better avoid it.

> Every file wanting to work with spinlocks, has to include that. However nobody
> (well, except those who really have to) bothers to look inside it.

Spinlocks are not portable and application code should avoid them.  We
need them for Windows because there is no way to statically initialize a
critical section.  But that is used only inside libgpg-error (and often
also in libintl).

> You are correct about configure macros. However we can have one 'threading'
> part for all posix systems.

Actually I am not proposing an API for threads. That would end up into
including the Windows pthread implementation and writing wrappers for
pthread.  For GnuPG we already use nPth as a threading library.
However, for libraries we need a basic locking feature and that is what
gpgrt_lock provides.  Currently we have ad-doc lock support at several
places (libgcrypt, gpgme) which is more or less correctly implemented
(Libgcrypt 1.6 misses support for Windows).

Unfortunately, there are more platforms than only Posix.  In general we
support Windows 32 and 64 bit, Windows CE, VMS, and Android.  Most
multi-component projects use a portability abstraction layer. GnuPG is
still missing a well-defined portability layer.  gpgrt will eventually
be ours.

> It definitely is. Consider gpgrt switching from pthread to some 'semaphores'.
> And let's suppose that sizeof(semaphore) > sizeof(pthread_mutex_t).
> Thus version checking code will become completely useless - if you pass

Frankly, the version checking is just there because it is good style to
add a version identifier to complex data structures.  It is not meant as
a real portability help but as a failsafe measurement:

  if (lock->vers != LOCK_ABI_VERSION)
    abort ();
  if (sizeof (gpgrt_lock_t) < sizeof (_gpgrt_lock_t))
    abort ();

For reason of cleanness and uniformity with Windows, I will rework the
definition to prepend the version information.

>> Thanks for the comments.  I'll change the build systems to allow the
>> inclusion of pre-generated lock objects for cross-compiling.
>
> I think this defeats the idea of encapsulation of information about
> pthread_mutex_t
> structure in the libc headers. Teoretically one would have to have a special
> copy of 'lock object' for each CPU-OS-libc combination. Does it worth trouble?

I think so.  I would love to not expose it in the header.  However,
static initializers are that useful that it is worth to run in some
trouble with cross-compiling.


Salam-Shalom,

   Werner

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