uncrustify nl_split_if_one_liner setting

... using uncrustify mod_paren_on_return config

White-space changes only, exception being the rare insertion of NL before
closing brace (couldn't find the option to disable that behavior).

I excluded some header files (e.g. sbbs.h) since uncrustify seemed to be doing
more harm than good there. I might just end up applying different set of rules
to .h files.

e.g. [can|is]_subject_something() is now named subject_[can|is]_something()

No functional change.

Increment SMBLIB version to 3.10

Fix issue #845: Changing system/OS time zone, changes dates/times of posted
messages

Sysops and users shouldn't notice any change unless they change the time zone
of their system/OS (not accounting changes for daylight/standard time) and
the result will be that message dates appear the same after such a change.

For backward compatibily, any stored time_t's in msghdr_t.when_written.time
(i.e. all existing SMB messages) will still be decoded and displayed properly.
We detect a time_t value by the upper 6 bits being non-zero. When the upper
6 bits of a when_written.time value are zero, then we know the 'year' is
stored in the 16-bits before the when_written field (never used bits of the
netattr field, now part of the when_t structure definition) and the Month,
Day, Hour, Minute, and Second of the wallclock at the poster's site are
encoded in the low 26 bits of the time field.

This also eliminates more uses of 32-bit time_t that'll likely start being
a problem 2038 and really fall over and die in 2106. At least messages'
posting dates won't have any issue now. The "when_imported" values could use
a similar treatment someday I suppose - and we could get rid of the
when_imported.zone value as its not really needed we could use those 16-bits
for the when_imported.year.

Didn't change anything with filebases (still using time_t's though the
when_written hdr field isn't used for much with regards to files).

Yes, we could have converted all imported "broken down" message dates to
UTC and continued to store them as a time_t using timegm() instead of mktime()
for conversion to time_t, and I considered that. But we would have needed to
create/use a flag in the message header to indicate such stored date/times
(since they'd have to go through different adjustment for original time zone
before display, basically reversing the logic of all the places we display the
message dates/times using localtime verus gmtime/UTC C RTL functions),
couldn't just initialize the time with a call to time() upon import of local
messages (unless the local timezone happened to be UTC). And in the end, we'd
still have a 32-bit time_t value. So this seemed the better path.

I would have liked to have stored the date fields in a more human readable
encoding (BCD or decimal, ala isoDate and isoTime_t), but I just didn't have
the spare bits in the fixed portion of message headers to be wasteful like
that.

Here's an example from smbutil v of a message header posted after this change:
  when_written     03292595 41E0 Fri Dec 20 18:22:21 2024 PST
  when_imported    6766265D 41E0 Fri Dec 20 18:22:21 2024 PST

Notice the difference in the hex encoding of the date/time between the 2
header fields: when_imported still uses time_t. The when_written.year value
isn't output here.

This is a code clean-up, no change in functionality

Fix issue #801

This resolves the conflict with MSG_HOLD definition in socket.h on MacOS:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/socket.h

And hey... [NET]MSG_HOLD isn't actually used anywhere? What's up with that.

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