Mailing List Archive

patch for libgcrypt 1.2.0 on pthreads
The new 1.2.0 gcrypt release has an include file that won't build if you
use GCRY_THREAD_OPTION_PTHREAD_IMPL because the types are wrong, and the
pthread struct isn't completely filled out. Here's the patch.

robey
Re: patch for libgcrypt 1.2.0 on pthreads [ In reply to ]
On Thu, 24 Jun 2004 16:16:24 -0700, Robey Pointer said:

> - pthread_mutex_t *lock = malloc (sizeof (pthread_mutex_t)); \
> + pthread_mutex_t *lock = (pthread_mutex_t *)malloc (sizeof (pthread_mutex_t)); \

malloc returns void* and that type must be assignable to any other
pointer object. Thus this patch does not make sense for C.

> - { int err = pthread_mutex_destroy (*lock); free (*lock); return err; } \
> +{ int err = pthread_mutex_destroy ((pthread_mutex_t *)*lock); free (*lock); return err; } \

See above.

> - gcry_pthread_mutex_lock, gcry_pthread_mutex_unlock }
> + gcry_pthread_mutex_lock, gcry_pthread_mutex_unlock, 0, 0, 0, 0, 0, 0, 0, 0}
Leaving out initializers will set the remaining elements to zero:

[#21] If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate, or
fewer characters in a string literal used to initialize an
array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized
implicitly the same as objects that have static storage
duration.

Thus I can't see a reason to change it.



Shalom-Salam,

Werner
Re: patch for libgcrypt 1.2.0 on pthreads [ In reply to ]
Werner Koch wrote:

>On Thu, 24 Jun 2004 16:16:24 -0700, Robey Pointer said:
>
>
>
>>- pthread_mutex_t *lock = malloc (sizeof (pthread_mutex_t)); \
>>+ pthread_mutex_t *lock = (pthread_mutex_t *)malloc (sizeof (pthread_mutex_t)); \
>>
>>
>
>malloc returns void* and that type must be assignable to any other
>pointer object. Thus this patch does not make sense for C.
>
>

I won't try to defend gcc. But it gives these errors without the patch:

TLSStream.cpp: In function `int gcry_pthread_mutex_init(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to
`pthread_mutex_t*'
TLSStream.cpp: In function `int gcry_pthread_mutex_destroy(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to
`pthread_mutex_t*'
TLSStream.cpp: In function `int gcry_pthread_mutex_lock(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to
`pthread_mutex_t*'
TLSStream.cpp: In function `int gcry_pthread_mutex_unlock(void**)':
TLSStream.cpp:18: error: invalid conversion from `void*' to
`pthread_mutex_t*'
TLSStream.cpp: At global scope:
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::read'
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::write'
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::select'
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::waitpid'
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::accept'
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::connect'
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::sendmsg'
TLSStream.cpp:18: warning: missing initializer for member `
gcry_thread_cbs::recvmsg'
make: *** [TLSStream.o] Error 1


Line 18 is:
GCRY_THREAD_OPTION_PTHREAD_IMPL;


So gcc (3.3.4) apparently doesn't think these conversions are valid
without casts.

robey
Re: patch for libgcrypt 1.2.0 on pthreads [ In reply to ]
On Tue, 29 Jun 2004 10:24:37 -0700, Robey Pointer said:

> I won't try to defend gcc. But it gives these errors without the patch:

> TLSStream.cpp: In function `int gcry_pthread_mutex_init(void**)':
> TLSStream.cpp:18: error: invalid conversion from `void*' to
> `pthread_mutex_t*'

You are using C++ and not C.

C++ is a different language than C - you have to make sure that your
C++ code uses plain C code correctly. The only thing we have made
sure is that the link conventions of Libgcrypt won't conflict with
C++.

GCRY_THREAD_OPTION_PTHREAD_IMPL is a convenience macro. Yo should use
your own implementation with C++. The manual describes how to do it.


Salam-Shalom,

Werner
Re: patch for libgcrypt 1.2.0 on pthreads [ In reply to ]
Werner Koch wrote:

>On Tue, 29 Jun 2004 10:24:37 -0700, Robey Pointer said:
>
>
>
>>I won't try to defend gcc. But it gives these errors without the patch:
>>
>>
>
>
>
>>TLSStream.cpp: In function `int gcry_pthread_mutex_init(void**)':
>>TLSStream.cpp:18: error: invalid conversion from `void*' to
>>`pthread_mutex_t*'
>>
>>
>
>You are using C++ and not C.
>
>C++ is a different language than C - you have to make sure that your
>C++ code uses plain C code correctly. The only thing we have made
>sure is that the link conventions of Libgcrypt won't conflict with
>C++.
>
>GCRY_THREAD_OPTION_PTHREAD_IMPL is a convenience macro. Yo should use
>your own implementation with C++. The manual describes how to do it.
>
>

That's okay. I was mostly passing the patch up as a convenience --
we're okay with using our forked version with it fixed the right way.

You probably want to remove the lines saying 'extern "C"' at the top of
gcrypt.h to avoid giving the impression that you support C++ usage.

robey
Re: patch for libgcrypt 1.2.0 on pthreads [ In reply to ]
* Werner Koch:

> malloc returns void* and that type must be assignable to any other
> pointer object. Thus this patch does not make sense for C.

The patch is for a header file, which probably should be made
C++-friendly if it's supposed to be a public interface. (But at least
in libgcrypt 1.1.90, the offending parts are missing from that file.)
Re: patch for libgcrypt 1.2.0 on pthreads [ In reply to ]
On Thu, 01 Jul 2004 00:12:47 +0200, Florian Weimer said:

> The patch is for a header file, which probably should be made
> C++-friendly if it's supposed to be a public interface. (But at least

True, but the offending macro is just a convenience for C code.

Werner
Re: patch for libgcrypt 1.2.0 on pthreads [ In reply to ]
On Wednesday 07 July 2004 13:03, Werner Koch wrote:
> On Thu, 01 Jul 2004 00:12:47 +0200, Florian Weimer said:
> > The patch is for a header file, which probably should be made
> > C++-friendly if it's supposed to be a public interface. (But at least
> True, but the offending macro is just a convenience for C code.

Well it could be inserted into an extern "C" block. Since the changes to
support c++ are that trivial, I don't think that we should introduce that
inconvenience to c++ programmers.

> Werner

--
Nikos Mavroyanopoulos