[Date Prev][Date Next]
Re: (ITS#4983) libldap_r/tls.c compile failure
>> tls.c: In function `tls_thread_self':
>> tls.c:412: error: invalid operands to binary /
>> tls.c:415: warning: comparison between pointer and integer
> Well, that was quick... my tls.c rev 1.154 patch, tls_thread_self(),
> deliberately causes that for non-integer thread types.
What to do? I found this in ITS#4723, from Howard Chu at 29 Nov 2006:
> In the current OpenSSL, the address of errno is tested as well. Since
> this is always unique per thread, there's really no need to set the id
> callback any more. The problem with just using CRYPTO_set_id_callback
> is that it doesn't work on platforms where a thread ID is not an
> integer (e.g. OS/390). I don't think CRYPTO_set_idptr_callback was
> available in earlier OpenSSL releases.
Yet Howard added CRYPTO_set_id_callback to tls.c (rev.144) the next day.
Why? Should we wrap CRYPTO_set_id_callback() in #if (OpenSSL is old)?
Well, I can think of a way the &errno hack can break: The OS could
create a small virtual address space which maps to different physical
memory for different threads, and put things like errno there.
OpenSSL 0.9.9 will apparently have CRYPTO_set_idptr_callback, so we
can use an #ifdef for that.
For whatever isn't handled above, my suggestion for now is to keep the
failure if ldap_pvt_thread_t is a struct/union or wider than long, and
see if anyone still complains.