List Info

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




Re: (ITS#4983) libldap_r/tls.c compile failure
country flaguser name
United States
2007-05-23 19:49:21
kurtOpenLDAP.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



[1]

about | contact  Other archives ( Real Estate discussion Medical topics )