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!

Upon successful download of a file, recalculate and store the user's download CPS (characters/bytes per second), mainly for subsequent transfer time estimates.

Mostly [s]printf format fixups

At one time, Synchronet was a 16-bit DOS project, plagued by the 16-bit [u]int, so long's were used everywhere > 16-bits were known to be needed/wanted (This is before the days of the standard sized types from stdint.h), and they've persisted.

But '[u]long int' is 64-bits on *nix 64-bit builds, 32-bits everywhere else (even 64-bit Windows builds if/when we ever get around to that), so this could lead to insidious bugs that would only show up on one flavor or the other. Since [u]int is 32-bits on everything we currently support, we'll use that instead of [u]long.

This "part 1" because I'm sure there's going to be warnings and errors from the GCC/Clang builds as a result, which I'll get to next.

Also resolved some 32 vs 64-bit 'long' issues/ambiguities that have long-remained. :-)

This commit also removes logon.lst file support.

There's a TODO block remaining in js_user.c for setting portions of a user's birthdate (e.g. just the year or month or day).

Use the is_valid_subnum() function before using the smb.subnum as an index into (s)cfg.sub[]. Related to the previous committed fix of writemsg(): leaving the global smb.subnum as -1 (INVALID_SUB) after replying to a post via email or netmail, resulting in a crash here.

Credits and daily free credits are accurate to the byte up to (a maximum) of 18446744073709551615 (that's 18 Exbibytes - 1).

User's upload and download byte stats are now similarly extended in maximum range, but the accuracy is only "to the byte" for values less than 10,000,000,000. Beyond that value, the accuracy declines, but is generally pretty damn accurate (to 4 decimal places beyond the nearest multiple of a power of 1024), so I don't expect that to be an issue. This method of storing upload/download byte stats allowed me to use the same 10-character user record fields in the user.dat file.

As a side-effect of this enhancements:
* User and file credit values are now expressed in multiples of powers of 1024 (e.g. 4.0G rather than 4,294,967,296).
* Free credits per day per security level has now been extended from 32 to 64-bits (to accommodate values >= 4GB).
* adjustuserrec() now longer takes the record length since we can easily determine that automatically and don't need more "sources of truth" that can be out-of-sync (e.g. the U_CDT field length going from 10 to 20 chars with this change).
* setting the stage for locale-dependent thousands-separators (e.g. space instead of comma) - currently still hard-coded to comma
* more/better support for files > 4GB in size (e.g. in the batch download queue)
* user_t ulong fields changed to either uint32_t or uint64_t - I didn't realize how many long/ulong's remained in the code (which are sometmies 32-bit, sometimes 64-bit) - ugh
* Steve's ultoac() function renamed to u32toac() and created a C++ wrapper that still uses the old name, for homage

So this started with addressing CID 174264: Big parameter passed by value (PASS_BY_VALUE), but then I fell down the constification rabbit hole. :-)

This will allow naming consistency in encode/*
This is the fix you're looking for Keyop. :)

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...

There were 2 bug identified by issue #230:
- the "Fwd:" prefix being added to the message subject was being treated as a filename. I first thought to just remove this subject tag, but then thought it best to just ignore obviously invalid filenames in the subject in the first place.

- when forwarding files to a netmail address, the 'to' extension (user number) is 0, so the file will be in the data/file/####.out directory of the sender instead.

We have 4 places (at least) where the message subjects are parsed and only one of those places currently supports quoted filenames (e.g. with spaces in them) and some of the others (e.g. QWK) don't support multiple filenames at all. That should be fixed.

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.

Don't display at all if smb_getplaintext() returns a blank string.
Don't display "(null)" if there's no text sub-type.

Since we're calling smb_getplaintext() manually here, and its not going to return the comment headers as part of the plain-text (the way smb_getmsgtxt() can), so we need to display find/display the comment headers first.

Copy some code from atcodes.cpp to show all the aux and network attributes.

Also, the MsgAttr text.dat string only contains 17 %s's but we were passing 18, so the last attribute (KillSent) would never be shown.

Instead, split this into 3 strings and just pass those 3 strings to the MsgAttr format string along with a ton of blank strings. So we don't have to keep updating the MsgAttr text.dat string every time we add more attribute flags (that was kind of ridiculous).

The return value of getlastmsg() is displayed as the total messages in a
sub-board when scanning subs. For sub-boards that allow voting, use the new
smb_msg_count() function to determine the number of displayable messages.

- hot spots are clickable screen areas (e.g. in menus and prompts) that   generate key-strokes
- commands may be from 1 to 127 ASCII-characters in length
- currently using the X10 mouse reporting mode, may change
- all mnemonics strings (~Example) are automatically hot-spots
- The new ~ @-code defines a hot spot
- Any screen-clear operation clears all hot spots
- sbbs now tracks the current screen (cursor position) row
- eliminated the old "tos" (top-of-screen) boolean (row == 0 indicates "tos")
- created an sbbs_t::ungetstr() method
- keep track if in pause (hit a key) prompt, for special mouse behavior

new JS console object:
- row property
- tos property is now read-only (and deprecated)
- new methods:
  add_hotspot()
  clear_hotspots()
  scroll_hotspots()

redrwstr() gets some UTF8 touch-ups as part of this commit. <shrug>

Don't suppress the display of the "from network address" just because there's
an '@' in the "from name" - some Internet email (e.g. SPAM) "From" names
include '@'s to try and follow the reader. <sigh>

wrapper for utf8_normalize_str() and utf8_replace_chars with the proper
arguments.
This will fix *a* problem with UTF-8 message not being converted to CP437 in
QWK packets correctly (we were just normalizing, not fully converting).
Also got rid of the defunct DLLCALL usage str_util.c

characters in message headers and body text will be converted to CP437.
Also include a new field in HEADERS.DAT: utf8 = true/false to indicate that
the message headers and body text contain UTF-8 encoding (not CP437).

would reuse the same buffer where the message subject (list of filenames)
was stored causing havok. Reported by Alterego (ALTERANT).

can't use it as an argument to sprintf(str, ...)
Also, use getfname()... more.

- bstrlen() moved to sbbs_t, accepts an option pmode argument so it can account
  for UTF-8 encoded strings correctly
- JS console.strlen() now accepts an optional pmode argument (e.g. P_UTF8)
- Renamed sbbs_t::utf8_to_cp437 to sbbs_t::print_utf8_as_cp437
- Create/use msghdr_hfield() to perform UTF-8->CP437 conversions as needed for
  printing/copying UTF-8 encoded message header fields.
- Defined XTRN_UTF8 misc setting flag. If a message editor does *not* have this
  flag, it is assumed to *not* support UTF-8. Will likely use this for UTF-8
  doors as some point too (none known to exist, yet).

show_msghdr()

flag in the message header.
When displaying message header fields containing UTF-8 using show_msghdr()
with text.dat string or with msghdr.asc and @-codes, do the "dance" to be sure
it's displayed correctly depending on the user's terminal (UTF-8 or not).

to putmg() when displaying messages in the sub on the terminal server.
E.g. to disable word-wrap for *all* messages displayed in a sub, set P_WORDWRAP
in sub_t.n_pmode.

support in putmsg/printfile, etc. on per-use basis.
Add per-sub-board P-mode flags (so "Extra Attribute Codes" can be disabled
on a per-sub-board basis).

with ZWNBSP/BOM UTF-8 sequence) and messages (with the "CHRS: UTF-8"
FTN control paragra or MIME "charset=utf-8" parts).
Not all UNICODE codepoints are supported (obviously).
Tested with various files from ftp://columbia.edu/kermit/charsets/
(e.g. test.utf8, utf8-boxes.txt)

to a text/html part of a multi-part MIME encoded message if no text/plain part
exists.
Changed smbmsg_t.charset to smbmsg_t.text_charset.
Added smbmsg_t.text_subtype (e.g. "plain" or "html").
Fixed issue with parsing parsed plain-text when the charset was the last
element of the MIME-part header.
MIMEDecodedPlainTextFmt text.dat line now includes the text sub-type arg

as well as the auxattr "Attach" when either FILEATTACH or MIMEATTACH is set
(requires an updated MsgAttr line in text.dat).

Expanded codes will not *not* go beyond the terminal column width (minus 1).
If you need the old/wrap behavior, add a "-W" modifier to your @-code.
If a length value is specified with -W, it is ignored.

- MSG_TO, MSG_FROM, MSG_SUBJECT now reflect the header values passed
  to sbbs_t::show_msghdr(), JS bbs.show_msg_header() and not necessarily the
  actual stored (e.g. MIME-encoded) header values.

New codes:
- MSG_CC - reflect a message's CC list, if it has one
- DATETIMEZONE - combines DATETIME and TIMEZONE in one string

used to display a CC list, when applicable.