Re: (ITS#4983) libldap_r/tls.c compile failure

[h.b.furuseth@usit.uio.no]

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.

-- 
Regards,
Hallvard