Internal codes are always treated as keys (in a database sense) and should be
unique, but they weren't always enforced to be unique in SCFG. There's still
a few config items with internal codes that aren't forced unique (e.g. chat
channels).

File Library short names and Mesage Group short names are also key values and
must be unique and that's now enforced as well.

Remove the default name for new File Libraries and Message Groups (which are
likely duplicate anyway).

This still appears to not fix valgrind on FreeBSD. :(
The background thread thing is interesting though because there's
an implication that the thread ID matters to GC in the assertion,
and we were very sloppy about requests in there.

No change in functionality, just code comprehension

corresponding wth new user DELDATE field

... an exception (e.g. chat_sec.js), so return false instead.

This fixes issue #864

Thank you Accession and Nelgin for the report

And tests to insure the expected behavior

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

Rob Swindell authored 2 months ago and Deucе committed 2 months ago

This means that when writing user.birthdate (in JS) for example, we will
always save the field in the proper (YYYYMMDD) format. This fixes issue #855.

Remove use of SM_EURODATE from userdat.c.

This commit includes new @-code MINSPACE (minimum diskspace required to allow
uploads) too (unrelated change).

For exposing the list path/file for a user's batch up/download lists

I noticed these redundant properties were being logged for every logon in
logon.jsonl. We don't need these properties separately enumerable, and really
they shouldn't be used anyway.

computer is an alias of host_name
modem is an alias of connection

Still using BOOL where we need Win32 API compatibility.
Using JSBool instead of BOOL or bool where it matters.
Changed most relevant TRUE/FALSE to true/false too (though it's not as critical).

You shouldn't need to #include <stdbool.h> anywhere now - gen_defs.h should do that automatically/correctly based on the language/version/tool. In C23, stdbool.h isn't even needed for bool/true/false definitions (they're keywords), so we don't bother including stdbool.h in that case.
Microsoft didn't define __STDC_VERSION__ in their older tool chains (even though they were C99 compatible and had stdbool.h), so we use a _MSC_VER check to know that there's a stdbool.h we should use in that case.

For other/old compilers (e.g. Borland C) we #define bool/true/false following the pattern of stdbool.h (doesn't use a typedef).

I didn't convert UIFC yet.

This addresses issue #698

Should calm the clang warnings reported by Deuce:

e.g.
passing 'char *[18]' to parameter of type 'const char **' discards qualifiers in nested pointer types

e.g. User.downlaoded_file() will now publish to the appropriate MQTT topic and changes to system.node_list[] will get published to MQTT.

Replaced _property_ver_list (array of numbers) with _property_ver_list (array
of objects) with a "ver" and (optional) "desc" property. This solves the
enumeration order problem with objects that have both manual and table-based
properties. Object's property tables (arrays of jsSyncPropertySpec) can now
(optionally) contain the property descriptions. For properties defined in this
manner, there will never be another mismatch between ther name/type and
description/version in the jsobjs.html (a problem has re-occurred several
times through the years with nebulous work-arounds).

We still use _property_desc_list arrays for additional (e.g. manually defined)
properties in such objects or just objects that only use one method of
property definition and are not subject to the enumeration order problem.

Fixed numerous typos.

Using more consistent terminology and HTML mark-up.

Some beautification and enhancement of readability, but nothing too major.

Uses the new ctrl/text.??.ini files (just a few words translated so far).
Adds the new "lang" user property (to user.tab and JS User class).
The language code is the 2-3 char (e.g. ISO 639-1) abbreviation of a language.
A "blank" language property value (the default), just means to use the
ctrl/text.dat contents.
User-selected alternate language file is loaded upon logon and in the
built-in/hard-coded user default settings menu.
More on the user default settings menu:
- AutoLogin via IP option ('I') to make room for new (I) Language option.
- The cold-keys menu option was removed to make room for Language option
  (via text.dat change to UserDefaultsHotKey)
- Any options disabled via blank text.dat strings will no longer result in
  supported command keys (that could accidentally be struck with hidden
  consequences/effect)
- The user_settings.js will need similar treatment

text/menu/<lang>/* is where alternate language menu files should be stored

New UserDefaultsLanguage text.dat string (inserted before new PasswordChar
string).

The request from Nightfox and Accession via DOVE-Net was to be able to set
a user's external editor even if there's no user logged-in.

These 2 user class properties in the JS object model were a bit special in
that they *only* wrote to the user database and did not immediately modify
the in-memory copy of the user_t structure, depending on the re-reading of
the user.dat/tab file to re-populate the current user_t structure when needed.
This didn't work if the current user is user #0 (no user).

So, set the current user_t.xedit and user_t.shell accordingly whenever those
JS properties are assigned a value (a string, the appropriate internal code).

No obvious bug fixes here, just future proofing.

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!

Mostly just bitfield->bit-flags.

No functional change, just a little clean-up.

Mainly capitalization, but some typos and added details. 

Right now, the only preference is reverse mail listings (oldest first
or newest first). These settings are only used when reading "your mail",
not any other kind of mail reading.

bbs.read_mail() now returns the user-adjusted loadmail_mode value and
this allows us to determine the user's preferences and save them after
this function/method is called. A readmail_mod can now return a number
(other than 0) and that will be used as the return value of this method.

sbbs_t::readmail() now does the adjustment of the passed lm_mode before
calling any installed readmail_mod, so if for example, deleted message
viewing is enabled by the sysop, those LM_* flags might be set now in
the argument to the readmail_mod, wherase they never would before.

There is not yet any way for the sysop to set a new user's default
mail_settings, they'll just default to 0 for now.

email_sec.js will get some adjustments to use/store the
user.mail_settings next.

Will track the user's last succsesful file-download transfer rate
in characters (bytes) per second.

I'm not calculating or storing this rate yet, but will be soon. This
will make the file download ETAs more realistic and no longer
hard-coded to 3000 cps (which now defaults to 10000 cps, to keep up
with the times).

New field added to user.tab placed adjacent to the other File xfer stats,
which means the leech attempt counter (likely always 0) was moved to the end
of the user record.

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

This can be used to force a close of the user.dat file, if open. Rather than
waiting for an out of scope User to get garbage-collected, this method could
be used to force a close of the user.dat file, if it's open.

Likely fix for the user.dat open file descriptor leak:
If js_CreateUserObject(cx,parent,cfg,"name",...) is called multiple times
(e.g. before login and after login), the successive calls will reuse the
previously allocated JS object and allocated private data memory. However, the
private data memory (which includes the descriptor of an open user.dat file,
if it has been opened), was always zeroed, even if it was being reused. This
would leak open file descriptor.

So any (pre)login scripts or web scripts that use the "user" object (which
is all zeroed-out before login) and then allows a user to subsequently login,
would leak a file descriptor.

When the 'number' property of an instance of User was incremented beyond the last user, the call to fgetuserdat() on subsequent property 'get' operation would fail and zero-out the user structure (including the user number). This resulted in an infinite loop in load/birthdays.js where the user number would go from lastuser to 1 in one operation (u.number++).

Reported by DesotoFireflite (VALHALLA)

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

Users with the 'O' restriction (automatically set if a new user has the same "real name" as another account, and that's allowed by the sysop) will send netmail from their alias and not their real name to prevent impersonation of another user.

It bothered Deuce having a web server setting in scfg_t/SCFG->File Options, so I moved this setting to [web_]startup_t and the sbbs.ini file.

The downside is that file_area.web_file_prefix is no longer available to JS environments outside of the web server and terminal server, but meh, probably not going to use it elsewhere anyway? I can imagine use cases for JSexec scripts to want to generate URLs to filebase files. If that ends up being a need, they'll have to find and parse the "right" sbbs.ini file to determine the vpath prefix. 

This macro has expanded to nothing for a while now and even before, the usage was misguided and unnecessary as explained in this video: https://www.youtube.com/watch?v=cjotPqQxxAY

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

New JS User.stats properties:
- read_mail_waiting
- unread_mail_waiting
- spam_waiting

New @-codes:
- MAILR (read mail waiting)
- MAILU (unread mail waiting)

And the corresponding MAILR# and MAILU# codes (for non-current user's stats).

Addresses feature request #191.

The default terminal columns (still 0/auto) can be overridden with the 'L' command from the user defaults menu. 

Also increased maximum manual terminal rows setting from 99 to 999 - this involved moving the record in user.dat, though the old record value is auto-migrated.