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. I wanted feedback from systems where that happens, since the OpenSSL doc says such systems are rare and this code can break there.

The CRYPTO_set_id_callback manpage (from openssl/doc/crypto/threads.pod) says the function expects an integer thread ID, but that the function is not needed if getpid() returns different answers for different threads. And that this may be dangerous to relay on because one might compile a program on a machine where this is true and then run it on a machine where it is false.

Anyway, possibly the correct fix is to not call this function on FreeBSD, it depends on getpid(). I have no idea. But since it presumably worked before:

The simplest fix is to just remove the 'ok' and 'Check' code. But then we can again silently compile to bad code when the thread type is not an integer.

Next simplest: simplify the 'ok' check to: enum { ok = sizeof(ldap_pvt_thread_t) <= sizeof(long) }; which will still let us know of systems where the conversion to ulong clearly loses data. Not quite a safe, since pointer<->integer conversions can do who-knows-what. But I guess OpenLDAP depends on those elsewhere.

(Can sizeof(long) be < sizeof(pointer) on FreeBSD?)

Also in any case cast tls_thread_self()'s return value to u.long.