Holding the lock around session establishment should not be needed,
but we need to protect tls_certificate read and usage.  Since we
don't have rwlocks in xpdev (yet?), hack together a crappy rwlock
that does what we need.

error: expected ‘)’ before string constant

Harumph.

Include function names. Include host:port in "Unable to connect" error.

Ideally, this would use startup.tls_error_level, but which one? And how?

Also, make a TODO comment to fix the fact that all JS Socket log messages
are logged to the terminal server log output. :-(

Replaced _property_ver_list (array of numbers) with _property_ver_list (array
of objects) with a "ver" and (optional) "desc" property. This solves the
enumeration order problem with objects that have both manual and table-based
properties. Object's property tables (arrays of jsSyncPropertySpec) can now
(optionally) contain the property descriptions. For properties defined in this
manner, there will never be another mismatch between ther name/type and
description/version in the jsobjs.html (a problem has re-occurred several
times through the years with nebulous work-arounds).

We still use _property_desc_list arrays for additional (e.g. manually defined)
properties in such objects or just objects that only use one method of
property definition and are not subject to the enumeration order problem.

Fixed numerous typos.

Using more consistent terminology and HTML mark-up.

Some beautification and enhancement of readability, but nothing too major.

I keep reverting/un-reverting the merge that includes an unrelated logon.cpp
change. So just manually remove this new code that was added to attempt to
fix issue #402 since I incorrectly concluded that sockopts.ini wasn't being
applied to new sockets created with ListeningSocket().

This reverts commit 110326c7.

We're already passing a sock_init callback (ls_cb) which is supposed to set
the socket options (call set_socket_options), so this change shouldn't be
necessary and reportedly caused more issues binding ircd sockets when running
ircd.js via jsexec (though I didn't see this myself).

This reverts commit ce1946fa.

This socket constructor did not get the global socket options treatment when
created (years ago).

This should fix issue #402 as reported by Nelgin and more recently by Keyop.

Mainly capitalization, but some typos and added details. 

This reverts commit 2cddddce.

This change was "wrong-headed" per Deuce and broke JS sends on
blocking sockets. Thanks for the help.

This fix for inifinite-wait on send() likely led to the infinite
BinkIT errors/log messages that led to commit b795cf6a.

The real fix for this problem (which can block all other timed
events from running), would be a Socket.poll() on the socket before
send in binkp.js.

BINKP is suddenly frequently hanging on sendsocket() on Vertrauen on Windows
(sending files to my Z1 hub) so try this as a solution.

CID 319135

Fix the return value of js_socket_sendfilesocket() while we're here (off_t instead of int).

Prevents weird issues with getting remote address.

Non-poll used the wrong value for calculating the high socket (which
is ignored on Win32, the only non-poll() user), and the socket was
being set in the wrong union member.

CID 319085 319089 319135 319142

CID 330950 and 319020

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

js_callback_t was not being properly retreived.

This appears to work and the event handler *should* work on other
event types already.

Note, this is *nix-only due to the use of poll().  select() will
need to be used for Windows to keep XP compatability.

Broken with the poll() update

Rather than depending on _WIN32 which is silly, make it clear what
exactly is being done and why.

Note that the spy socket stuff and some external stuff on *nix have
had the select() implementation removed.  To support using select()
on !Win32 will require de-refactoring that's not really worth doing.
Instead, just use #error and reference the commit where the old
code can be found.

Still needs updates in services_thread(), CGI stuff in websrvr.c,
and sbbs_t::external()

While errors on transmit seem to be handled well, errors on receive
do not, especially through js_recv_line() which has been seen to
trigger a large number (hundreds) of ECONNRESET errors.  To prevent
this, simply close the socket when an otherwise unhandled error
occurs.

Almost certainly fixes that issue, but the underlying cause is still
undetermined.  The calling script (imapservice.js) was checking
Socket.is_connected after each recv_line() call, so if the socket
was actually reset, it would be expected to only call it once.

An alternative would be to explicitly handle the error that is
seen (CRYPT_ERROR_PARAM1), but let's try a generic fix first and see
of anything breaks because of it.  Most likely issue would be an
inability to recv() data after calling shutdown(), but I don't think
many people do that except to move the TIME_WAIT to where they want
it.

The socket set allocated by xpms_create() was never freed. Found by Coverity.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

Only observed on Windows, the option value variable (val) was uninitialized so querying byte-sized options using WinSock getsockopt() would leave the MSB of the value as undefined (garbage), resulting in sockinfo.js output like this:
KEEPALIVE = -858993663
instead of this:
KEEPALIVE = 1