This Coverity reported issue was previously resolved (incorrectly) with
commit d02fc1a2 which also introduced a bug that ate all the unexpected
cursor position report characters (causing issue #304).

The correct fix was to compare the response length against the buffer size
minus one, to leave room for the NUL terminator.

While fixing this and issue #304, I noticed that this function was using the
response length ('rsp') as both the state machine state and string length,
which didn't work right if a nearly-matching report/response was received:
the x/y values would have been stripped from the response before stuffing
in the keyboard input buffer. So a bit of a refactor here using a proper
state machine variable.

Unexpected characters received (maybe typed by the user) were supposed to
be stuffed in the keyboard input buffer using ungetstr(), but the input string
was cleared rather than NUL-terminated before logging the expected character
and calling ungetstr(), so nothing (a blank string) was logged and nothing was
stuffed in the keyboard input-buffer in this case. Just an off-by-one bug.

This should fix issue #304. Thanks to Keyop and Nelgin for their persistence
in reporting and testing (in #synchronet at irc.synchro.net).

I didn't look closely enough at which write() call I was instrumenting.
This is now more useful, though I think we already found the root-cause
based on different log output ("Unexpected ansi_getxy response").

This just resulted in a lot of unhelpful noise in the log output

When reading and writing characters to chat files, log each with a debug-level
log message. If a read or a write fails, log with an error-level log message.

This will hopefully help root-cause and resolve issue #304.

Don't use cnflib.js any longer, now obsolete

Untested, but matches implementation from https://github.com/veeso/termiWin/blob/master/src/termiWin.c

and declare function in comio.h

Rather than only matching exact zone numbers as a final "nearest" address
search, use a "nearest zone" matching algorithm ("nearest" being the most
mathematically near). This way, replying to netmail from a zone 2 address
would always match a zone 1 source address, regardless of how many othernet
addresses are configured and which order they are configured in SCFG.

Fixes issue #447 reported by Charles Blackburn (FBOBBS)

We no longer use/require the USE_DOSEMU definition anywhere else, so
this was just a miss when the DOSEMU patch was perm-enabled.

sbbs3/../xpdev/netwrap.h:45:27: warning: 'parseIPv6Address' has C-linkage specified, but returns incomplete type 'struct in6_addr' which could be incompatible with C [-Wreturn-type-c-linkage]
DLLEXPORT struct in6_addr parseIPv6Address(const char*);
                          ^

New Medium impact and a low impact issue still needs to be triaged.

Previously, when a user disconnected or ran out of time while running a
stdio-based external program on *nix, if the program was still running, we'd
send it a SIGHUP, wait up to 10 seconds for the process to terminate and if
it did not, terminate it (ungracefully) with SIGKILL. Since some programs
catch SIGTERM (and not SIGHUP) to indicate a termination request, we now will
first attempt a SIGHUP, wait up to 5 seconds for the process to terminate and
if it does not, then send a SIGTERM and wait up to another 5 seconds for it
to terminate and if it doesn't, then finally send it a SIGKILL (which cannot
be caught and always results in an ungraceful termination of the child
process).

This doesn't resolve any specific problem with any specific stdio-based
external program, but I was playing around with ESR's port of Adventure
(https://gitlab.com/esr/open-adventure) and a new auto-save/restore of game
state and noticed that we weren't using SIGTERM for this situation, though we
should have. Most modern programs, if they catch SIGHUP at all, use it to
indicate a refresh of configuration or data files, not a termination request
(or indication that a user has "hung up"). So SIGTERM is more reasonable to be
expected to be caught and initiate the graceful termination of the child
program that we're hoping for.

Per Deon (ALTERANT) via DOVE-Net:

Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS connection accepted from:
2402:1f00:8101:b3c:1000::2 port 55338
Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS TLS ERROR 'Server
certificate has expired' (-3) setting private key
Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS TLS ERROR 'Data has not
been initialised' (-11) setting session active

Which was odd, because my cert was renewed.

I forced renewed it, and confirmed it was valid, but they were still failing.

I noticed that letsyncrypt only recycles the web, which is probably the issue.
Once I recycled everything, binkps connections started working again.

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

Fixes #401

Fixes #368

... QWKnet hub sub-boards

The internal code is not "prepped" when read by SCFG, so the code is actually
blank (empty string) when saved in SCFG and is thus not useable for writing
the value to .ini, as in this case.

This fixes issue #441 (for the new_config_format branch) as reported by Nelgin

DDMsgReader: Added a mouse click hotspot for ? for message list mode

See merge request !210

DDMsgReader: Refactored how email replies are done (passing the header to the appropriate functions, not using ungetstr() when prompting for the message subject

See merge request !209

Eric Oulashin authored 2 years ago and Rob Swindell committed 2 years ago

DDMsgReader: Refactored how email replies are done (passing the header to the appropriate functions, not using ungetstr() when prompting for the message subject

Section suffix is the decimal ASCII value, not the character itself.
Fix issue #440 as reported by Nelgin

not just 'settings'

Fix issue 439. Thanks Nelgin!

'execution_ars' not 'run_ars'.