This macro hasn't done anything meaningful since we stopped using really old
versions of Borland compilers (and std libraries) where strerror() returned a
string terminated with a line-feed (\n) character.

These should only be used in the sbbs_t methods called by node_thread or
event_thread. Any other thread-shared sbbs_t instances should not use these
methods since they share a single error description string buffer.

As reported by Deon on DOVE-Net: type 2.2 packet generation was not (since
SBBSecho v3.0) setting the origin and destination point values correctly:
was leaving the packet type 2.0 date values in these fields.

Also, zero-out the reserved bytes in the type 2.2 packet header (don't leave
the type 2.0 date values in there).

Thanks for the report Deon!

If the oldlen param value is less than one, set to a sane non-zero value (79).
Fix issue #576

<phigz> what would you convert ansi to so it displays right when written out from a .js file?

Now, you can use 'ans2asc -esc' for this purpose.

Not sure how I missed this before <shrug>

This should fix the SBBS-MSVC build in CI.

This utility doesn't expand Ctrl-A codes, so just strip them.

The directories of the *first* library was always the target of the (new)
"Clone Settings" option. We're using a dir_t for each lib's dir_defaults, but
that doesn't mean the dir_defaults.lib is initialized to a correct libnum
(it's not), so don't use it.

Should use safe_strerror() here instead... later.

e.g. runtime error: store to misaligned address 0x7ffec33195e3 for type
'short int', which requires 2 byte alignment

These aren't a problem for x86, but could be a problem for some other CPU
architectures that don't support unaligned access. I didn't use memcpy() to
resolve this (though that would've worked) to make this change endian agnostic.

the hash lib dependency was missing

scfgsys.c: In function ‘edit_sys_delmsg_policy’:
scfgsys.c:498:3: error: case label does not reduce to an integer constant
  498 |   case SM_USRVDELM | SM_SYSVDELM:
scfgsys.c:504:3: error: case label does not reduce to an integer constant
  504 |   case SM_SYSVDELM:

No obvious bug fixes here, just future proofing.

New issue as result signed int total_dirs (increased from uint16_t).

Adding and removing typecasts and changing some types (of ints).

So Clang-FreeBSD was warning (in compiles of scfg/scfg*.c by Deuce):
result of comparison of constant 100000 with expression of type 'uint16_t'
(aka 'unsigned short') is always true

Why? Cause a uint16_t's max value is 65535 (less than 100000). Sure we could
have just lowered the UIFC max number of config items to 65535, but that would
have been too easy. And why are these compared-with values of type uint16_t to
begin with? Because most ctrl/*.cnf lists (of configuration items) were
limited to 65535 entries cause ... 16-bit DOS, historically. Now that *.cnf
files aren't used, we could just increase these scfg_t.*_total type sizes from
16 to 32-bits, yeah? The result is this commit.

I went to (signed) int so we could still keep -1 as the special illegal
sub/dir num value (e.g. INVALID_SUB, which is sometimes used to indicate the
email message base). Theoretically, 2 billion configuration items could be
supported in these lists, but SCFG will limit you to 100000 anyway. So there's
a whole lot of s/uint/int in this commit.

I'd be very surprised if this doesn't result in some new GCC/Clang warnings,
but at least the old "comparison of constant 100000" warnings are now gone!

C allows char* p = '\0' (which is clearly wrong)
C++ does not.

format specifies type 'unsigned short' but the argument has type 'unsigned int'

"unary minus operator applied to unsigned type, result still unsigned"

Even though this same code compiled and worked as expected with GCC.

I'm doing builds for my jail (which doesn't have libmosquitto) on
my system that does have it now, so I need to disable it manually.

Mostly (all?) about unchecked return values. Unexpected failures to read or
write some files could've definitely led to some weird bugs.

Or even weirder, u_long?

And dereffing a ulong/u_long pointer where you expect to find an IPv4 address?
Yet even weirder still.

Fix that spit: It appears in_addr_t is defined on all platforms (?), so use
that type instead.

No known sightings of these sites actually being the location of a segfault,
but as we learned from the segfaults in rblchk(), the first entry in the
h_addr_list can be NULL in some cases.

I'm not sure why this one only started popping up now, but h_addr_list is a
NULL-terminated list and it makes perfect sense that the first entry could
be the NULL-terminator.

gethostbyname is obsolete/deprecated and we should address that in a separate
commit.

A bunch of possible (but often, not really) use of undefined values.
Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets).

Other than some added diagnostics upon some of these unexpected syscall
failures, there should be no change in behavior from this commit.

Apparently the mosquitto.h won't always be installed in /usr/include on
all systems (e.g. Deuce's FreeBSD gitlab-runner system)

It was redudnant having "External Editors" under "External Programs" (they're
all external, yeah?) and of course, "Editors of what?"

So yeah, existing docs are now all wrong. :-)

Keyop reported an issue via irc whereby a user that failed to download a file
would leave the node "hung" in "downloading via telnet" node status even
though the user had long since disconnected and the log reflected that the
terminal server was aware of this:

term Node 4 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 4 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 4 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 4 connection reset by peer on send
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 disconnected
term Node 4 !ERROR 32 sending on socket 102

and

term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 3 connection reset by peer on receive
term Node 3 !ERROR 32 sending on socket 96

These nodes were then locked up in call to passthru_socket_activate(false)
as reported by gdb, e.g.

Looking at passthru_socket_activate(), the deactivation path (called at the
end of external() in this case), it was clear that this could be an infinite
loop in the case the user had disconnected:

    do { // Allow time for the passthru_thread to move any pending socket data to the outbuf
        SLEEP(100); // Before the node_thread starts sending its own data to the outbuf
    } while(RingBufFull(&outbuf));

These flush/purge loops aren't strictly needed if the user has disconnected,
but as can be seen by the above logs, the terminal server may not know that
(the socket may not indicate disconnect) before passthru_socket_activate()
is called by external().

So... worst case, just do the activation and deactivation buffer flushes
and purges for 60 seconds.

"I can't think of a reason I'd want scfg and echocfg to remain windows (gui) programs"
                                              -- Digital Man

While I'm here, hack up some SyncTERM vcxproj stuff (which almost
certainly doesn't work, but since I can actually test it now, I
may as well try)

... or else any pending published messages aren't sent.