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.

Not having that dependency is the entire point of it.

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

Another Coverity-issued-fixed-introduced-bug.

Failure to remove a non-existant file is not reason for failure.

ARE YOU HAPPY NOW CYAN?!?!

Looks like I was partially restoring old code before I stopped.

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.

Rather than defaulting to zero lines high and the width of the title,
default to the entire screen area.

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

Used by gcc in warnings.

Could be useful for knowing if you need to increase MaxClients for typical
usage.

Thanks Mr. Executive Chicken esq. for the telephone call and bug report.

2 new configuration params: MaxLogSize (default: 10M) and MaxLogsKept (10)

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.

It fixed an issue in js_socket.c, no reason to expect better
behaviour with TLS.  This may fix SZ YModem-G transfers on
cvs.synchro.net...

Do not get/set these values on other OSs.  Fixes a segfault caused
by default_dosemuconf_path being undefined on FreeBSD, but would
also happen on any other *nix platform (ie: OpenBSD, etc).

Something weird is happening to the cryptlib session when SZ sends
a lot of data... no real clues left.

This issue may actually be a rekey issue, to clear this, we need
to call cryptPopData(), but we can pop zero bytes.

In this case, re-try the flush.

During YModem-G transfers, the previous 5-second timeout was
exceeded.

Just rename ESCDELAY member to escdelay.

remove() is expected to fail in this scenario sometimes depending
on how writemsg() is used - in the error case, the user was trying
to edit his .plan file with the ;plan command:
term Node 10 <Deuce> !ERROR 11 (Resource temporarily unavailable) in writemsg.cpp line 1232 (editfile) removing "/sbbs/node10/temp/INPUT.MSG" access=0

Thanks for the bug report!

or any lines that were only terminated with carriage-return (\r)
since these are treated rather-oddly by the FTN software as a
line-ending and line-feeds are to be ignored. So transfer \r to \n
on output and ignore the \n's in the body text.

Currently, this is hard-coding the name of the key, which should
be read from the letsyncrypt.ini file in case someone is using an
ACME v2 service that is not provided by letsyncrypt.org.

By displaying "<DISABLED>" instead of the command-line in the event list.

See if this resolves rjwboys reported error:
threadwrap.h:204:42: error: expected expression before ‘do’
 #define protected_uint32_init(pval, val) atomic_init(pval, val)

This option fixes the fact that the following two lines sometimes
place the variables in different scopes at the top-level of included
scripts:
var x = 1;
y = 2;

I plan to use this to experiment on if this is what's causing much
of the remaining scope chain weirdness... it certain explains some
things we've been seeing (and possibly even things like the METHODJIT
issues DigitalMan saw yesterday).

Enabling in sbbs/jsexec is a much bigger lift, but this change may
end up being all upside... the docs have suggested this option always
be set since it was originally introduced, and now that I understand
scopes better, it's pretty clear why that is.