h.b.furuseth@usit.uio.no writes:
kurt@OpenLDAP.org writes:
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.