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.

Make Coverity happy.

Hopefully not introducing any bugs in the process.

The new subject line parsing (with quoted-filename support) had a NULL-pointer deref built-in.

Also fixed a few Coverity-reported issues.

Caught by Coverity.

Addresses Coverity's NEGATIVE_RETURNS bug-checker issue.

Identified by Coverity.

To make Coverity and my adult-self happy.

As tested and reported in FIDONEWS by Michiel van der Vlist, 2:280/5555, SBBSecho would use the "best match" FidoNet AKA for the originating address when replying to PING netmail messages and not necessarily the original destination address of the ping request. For systems that have multiple addresses (AKAs) that could be considered appropriate originating addresses for the requesting node address (e.g. multiple addresses in the same zone or zone/net), this could cause a confusion for the PING requester.

The create_netmail() function now accepts an optional source (orig) address parameter and the PING response logic passes the netmail's destination address for the reply message's originating (source) address.

I noticed that AreaMgr responses also follow the same logic as PING responses (just use the best-fit AKA, not necessarily the same address as the original request's destination address) - but I did not choose to address that "issue" at this time.

Don't return an error if the node#/node.cnf file can't be opened for all uses of load_cfg() except from the terminal server. This fixes #214 for Tracker1

The previous committed fix/issue raised some additional concerns about this "parity" bit:

Something I didn't notice before from the ZMODEM spec:
"The hex header receiving routine ignores parity."

And looking at lrzsz's zm.c, I see it goes even further and ignores the "parity" bit on the ZPAD and ZDLE bytes proceeding the frame encoding byte as well as in the frame encoding byte itself (so ZHEX, 'B' 0x22 and 0xC2 should be treated as equivalent).

I find it strange that some ZMODEM implementations (e.g. chuck's zshhdr()) would send the terminating LF with the even-parity bit set, but not set the even-parity flag for any of the frame content bytes. And then, expect that the parity flag may be set on incoming hex headers. I suppose it makes sense for 7-E-1 connections, but then the transmitted terminating LF would have had its parity flag set automatically (would not need to be set manually in the code). Add to the mysteries of ZMODEM that will likely never be solved.

Some ZMODEM implementations set the high bit (even parity?) when sending this '\n' terminator.
As reported via IRC:
<Keyop> sexyz: !zmodem_recv_hex_header HEX header not terminated with LF: 138 (8Ah)

After calculating i (offset in list to top of window), if it's less
than zero, apply it to bar and set i = 0.

Fixes #218

Feature requested (?) by u/jumbotronjim on https://www.reddit.com/r/synchronet/:

If the client connection is from a blocked IP address (in ip[-silent].can), but still manages to get through the web server and websocketservice and have their correct IP address reported via Telnet Location, terminate the connection. Seems dubious.

Fix issue reported WitNik (BGGRSCYN) on DOVE-Net:
```
sbbs@raspberrypi:~ $ /sbbs/exec/umonitor -iC
...
sh: 1: /sbbs/exec/syncterm-iC: not found
```

These configuration properties were not previously exposed via JS.

No immediate use/need, but I *almost* did. :-)

"Old style" (e.g. FTN netmail) attachments put the filename(s) in the message subject. Supported quoted-filenames in the message subject (i.e. to support filenames with spaces in them) in addition to the traditional space-delimited filenames. Mixing quoted and space-delimited filenames (for multiple attached files) in a single message subject is supported.

It should be either EACCESS or EAGAIN, but still, could be useful to know.

Since on 2.17, pthread_afork() is not in libc, -lpthread must be
after -lcl (library link order issue)

Fixes #211

BIG thanks to Scott Comstock for giving me access to his box to fix
this.

Also change the wording of the -D option to be more descriptive.

The "EchoLists" help menu only worked when you first enter the sub-menu and would get wiped out by subsequent child-menu help text.

Filled out the "Configuring an EchoList" help text.

Fixed issue seen where deleting an EchoList's Required Key didn't set the "dirty config" flag, so saving of changes was not prompted when exiting (if that was the only change made).

Also, it's not technically an option, so remove from the option list.

Fixes the Win32 build.

Done.

At Tracker1's request/suggestion.

jsexec -Itrue
...
Result (boolean): true

More elaborate expressions can be evaluated and white-space included by quoting the "-I expression".

Also, send all cmd-line usage errors to stderr and syntax help to stdout, always (Deuce's request).

Stop lying. Programming is hard enough already.

The extra spaces caused the centering of the cryptlib version to be offset (not exactly centered).

Now the default bar is INT_MAX, so it always gets corrected when
left as default.

This is good.

Instead of setting bar to zero when possible, set it to the number
of displayed options, putting the lightbar at the bottom of the
displayed list instead of at the top.