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

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

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.

-- 
Regards,
Hallvard