On Sat, 2 May 1998, it was written:
> modifications, which I have collected in the form of 'diff' output (I won't
> spam them to the list, but they are available if someone wants them). I'm
> not worried about most of the changes, but a few make me nervous. In par-
> ticular:
>
> #define SHUTDOWN(fd) closesocket(fd)
>
> from e_os.h and changing "i=getsockopt(sock,SOL_SOCKET,SO_ERROR,&j,&size)"
e_os.h is where all the OS specific uglies should go anyway :-).
> to "i=0; j=errno" in apps/s_socket.c and crypto/bio/b_sock.c. In the first,
> BeOS doesn't have shutdown(), so I figured "closesocket()" was all that was
shutdown actually sends relevent TCP messages to close the socket for further
read/writes. It is not critical and I do suspect that closesocket() is the
correct thing to do.
> needed... For the second, BeOS does not support SO_ERROR and AFAIK does not
> provide a way to check any errors on a socket; you have to check errno after
> the call. In the SSLeay code BIO_sock_error() appeared to be called before
> any other system functions after a read or write....but I'm not that familiar
> with it.
Ok, the place where I mostly need this call is when doing non-blocking
connects. We do a 'connect()' that returns -1, EWOULDBLOCK. When select()
says that IO is possible, I use the SO_ERROR call to find out if the socket
connected or failed, depending on the error code. Even in a non-threaded
environment this is needed since select() may have just reported IO is
possible on 57 different descriptors, and if I only want notification that the
socket is connected, I don't want to do a read/write at this point in time.
There should be some way of doing this. errno is a bit of an evil hack when
doing multi-threaded stuff and for out of band error stuff :-). BeOS may have
connect(2) defined differently so a second call on the EWOULDBLOCK descriptor
may return the new status (instead of re-connecting).
> Due to the BeOS's highly multi-threaded philosophy, I think it would be best
> to include the thread setup and locking functions by default. But where
> should they be added? (Currently they're in crypto/threads/th-lock.c, but
> as far as I can tell that doesn't get compiled anywhere.)
Ignore crypto/threads :-). crypto/cryptlib.c is the place to look.
The best system would to be to define default functions for the locking
functions (locking_callback, add_lock_callback and id_callback).
> p.s. I have not built it as a shared library (I'm still trying to figure
> out just how to do that) but I will do that eventually; I doubt it will
> require any additional source modifications.
I did have ssl/ssl.c and crypto/crypto.c which included all the C files into
2. Building a shared library could be as simple as compiling these 2 files.
I have not updated them for 0.9.0 unfortunatly, and if you are using the x86
assember, you have to tweak things a little more. I don't know if BeOS uses
.def file type things, but if it does, full lists of exported function names
can be found in util/libeay.num and util/libssl.num.
I'd definitly be interested in including the BeOS changes, but I'd also be
interested in geting the non-blocking connect stuff figured out :-).
eric
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
