These @-codes can be used to construct ftp[s] and http[s] URLs to display to
users. For use in new/optional display file text/menu/download.*

Add optional configurable 'vpath' (per-directory) for directories that have
web/ftp aliases, so they preferred/short path (alias) will be used in the
expanded @-codes.

In SCFG, display each directory's virtual file path ([auto-generated] or set
manually).

getfilevpath() no longer assumes the target buf is >= MAX_PATH+1 bytes long

Add dir_vpath() to get a directory's vpath

Extend maximum file library parent directory from 47 to 100 chars. This limit
was likely imposed because we didn't have horiztonal scrolling input in UIFC
getstr() support at the time. We're no longer limited by that.

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

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.

When the system time zone is not UTC, but the sysop wants to display some
dates and times in UTC, they can now use these @-codes to do that:
- TIME_UTC
- DATE_UTC
- UTC:fmt
- DATETIME_UTC
- MSG_DATE_UTC

Addresses Clang warnings about deprecation

getnodedat() now performs a non-locked read by default.

Perform more checks of getnodedat() return value before calling putnodedat()
to avoid unintentionally zeroing out node.dab records.

Add/use unlocknodedat() method for unlocking a node.dab record without
writing.

Note: The userdat.c getnodedat() and putnodedat() still return int (i.e. 0 on
success), so that can be confusing.

Although we've added (in SBBS v3.20) configurable numeric date input/display
formats for the system, the output was still ambiguous for users (e.g.
NN/NN/NN which could be interpretted a number of ways), so I've added an option
to choose "verbal" short date formats to be displayed where possible instead.
The same value separate from the numeric format (whatever the sysop chose) is
used in the verbal date output, but since month name abbreviations are 3
characters, only one separator is used (to keep the output length fixed at 8
characters).

The new "Verbal" short date display format is choosable in the SCFG wizard and
via SCFG->System->Short Date Format.

Add JS console.ansi_getdims()

Use sbbs_t::getdimensions() or JS console.getdimensions() to move user
cols/rows values to run-time console values (querying ANSI terminal if
appropriate/supported).

JS console.pushxy(), popxy(), and gotoxy() all return Boolean now.

sbbs_t::getdimensions() and its JS wrapper is now the proper way to propagate
user's cols/rows settings to the run-time console values. This was done
(post-login) only via use of the TERMROWS and TERMCOLS @-codes in
user_settings.js. Weird.

... when PETSCII terminal in use.

For those sysops using editors that don't automatically or easily add this
character to their SEQ art files when needed.

New key "rainbow" in ctrl/attr.ini
New Ctrl-A codes: 'X' to turn on repeating/wrapping rainbow attributes,
 'x' to turn on non-repeating/wrapping rainbow attributes.
New @-code: RAINBOW:x to set the list of (comma-separated) rainbow attribute
 values (in same form as attr.ini).
 When used in a display file, the rainbow attribute change is temporary.

Ever wanted to add alternating attributes to @-code expanded text in display
files? Now you can.

Also can be used to easily/quickly create display files with repeating
elements (e.g. commands/options) using alternating attributes.

The "default" mnemonic string attributes are still set in ctrl/attr.cfg,
but now, each mnemonic string (e.g. from text.dat or passed to JS
console.mnemonics()) can include a "MNE:" @-code to over-ride the default
mnemonic string attributes (low, high, and command). If the "high"
attribute isn't specified, it defaults to the same color as the "low"
attribute with the "high intensity" flag flipped. The "cmd" attribute
defaults to whatever was included in the attr.cfg, if not specified.
Technically, the separator between the attributes can be any non-valid
attribute character (e.g. symbol).

Renamed (really old function) attrstr() to strtoattr() since its usage now
more closely resembles other std C strto* functions (has an 'endptr' arg).

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.

Don't corrupt UTF-8 strings with SAFECOPY() (use new SAFECOPY_UTF8).

Some terminals (notably, Windows Terminal) display zero width UNICODE chars
as a single column-wide space. <sigh> Auto-detect the zero-width "width"
(1 or 0) of the terminal during connection and UTF-8 auto-detection.

getstr() works a lot better now with UTF-8 strings with wide chars (e.g.
emojis), but likely much more to do.

Silly me, this is C++, do the C++ thing

No functional change.

Seems a useful function to have on hand. Especially now that it's "fixed"
(will convert "1234" to "1,234").

I noticed while testing the previous commit that 4 digit values weren't
thousands-separated, while larger values were. I'm not sure why this
non-zero index check was in this loop, but appears to be a bug.

- bbs.expand_atcodes() now supports formatting (did not before this)
- text.dat/ini strings now support @-code formatting (did not before this)
  (this fixes issue #697)
- bbs.atcode() now supports more complete formatting (only supported -R/-L
  previously)

The -W (wide) formatting code is not supported in these cases since that code
currently sends UNICODE sequences directly to UTF-8 terminals, when used.

The 5th character must be a digit.

Prevent future stupidity such as happened with recently added and then
fixed NODE_USER @-code.

Since "NODE*" is a match for a node number status (ugh), and this comparison
happened before the comparison for "NODE_USER", we'd never hit that condition.
Thought I tested this before original commit, but I guess I did not. Oops.

Needed for exactly reproducing built-in node status string formatting using
@-codes (only).

To complete the request from: Max (WESTLINE)

  Is it possible to do a new dateformat in scfg
  In sweden we using YYYY-MM-DD format as standard.

The default will be '/'.  Technically, any separator is possible by editing
the "date_sep" value in the global section of main.ini.  SCFG allows the
most popular separators: /.- and space.

... and YYYY/MM/DD for birthdate input/display.

Now set in SCFG->System (not toggle options) and stored in the "date_fmt" key
(new) in main.ini. The old sys_misc SM_EURODATE flag is deprecated (but used
to determine the default value of date_fmt when not present).

As requested from: Max (WESTLINE)

  Is it possible to do a new dateformat in scfg
  In sweden we using YYYY-MM-DD format as standard.

Actually tested myself this time, needed a lot more than first appearances.

Also includes a security/safety enhancement where the @-code expanded string
is *not* used as an sprintf format string. Supporting both format specifiers
and @-codes in a single text.dat string is tricky (always has been).

For Accession.

The first word of the message recipient or author's name.

For Accession.

Whoohoo, I'm a reel STL programmerz n0w!

sbbs_t::mnemonics() now supports @-codes immediately following the tilde
(e.g. ~@Yes@) to use the first character of a dynamically-replaced
(e.g. localized/translated) text string as a command key.
Fixed issue in sbbs_t::mnemonics if multiple @-codes were specified in the
string, but no space characters (just noticed this bug while reviewing).

Created: sbbs_t::expand_atcodes() - used by sbbs_t::mnemonics(), exposed in
JS as bbs.expand_atcodes().

bbs.text and system.text now have properties: each text string ID is the
property name and the text index number (1-based) is the property value -
enabling fast text string lookup without load/require text.js

Constified sbbs_t::atcode() and attrstr() - not too painful

Deprecated YNQP text.dat string in favor of (the first character of)
  "Yes" and "No" text strings and new strings: "Quit", and "PasswordChar"

Other text.dat changes: ListKey->List, AllKey->Unused853
More new text.dat strings: Which, Next, Previous, Language, LANG
Deprecate the "AllKey" text string
Create/use sbbs_t::all_key() - first character of "All" text string

New JS console properties that present common (possibly localized) command
keys: yes_key, no_key, quit_key, all_key, list_key, next_key, prev_key

The TEXT:<x> @-code can now be used with the text.dat string ID rather than
the text.dat string number, if preferred.

For convenience and brevity, ALL text.dat string IDs are now valid @-codes
(case-sensitive). While this functionality is redundant with the TEXT: @-code
now, if there are any conflicts between new/existing @-codes and text.dat
string IDs, the TEXT: @-code can be used to overcome such conflicts.

This should help with localization (to other languages) by using common
single-word replacements (Which, Quit, Next, etc.) in text.dat strings.

This fixes issue #629

I'll add detailed docs to http://wiki.synchro.net/custom:atcodes soon, but the
list is:

- TERMTYPE
- TERMROWS
- TERMCOLS
- AUTOTERM
- ANSI
- ASCII
- COLOR
- ICE
- RIP
- PETSCII
- SWAPDEL
- UTF8
- MOUSE
- UPAUSE
- SPIN
- PAUSESPIN
- EXPERT
- HOTKEYS
- MSGCLS
- REMSUBS
- FILEDESC
- FILEFLAG
- AUTOHANG
- AUTOLOGON
- QUIET
- ASKNSCAN
- ASKSSCAN
- ANFSCAN
- EDITOR
- SHELL

This should (at least mostly) address the issue #629

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!

This code will do nothing if there's no user logged-in or their terminal is
not ANSI or their terminal dimensions (rows and cols) are set to specific
values (not auto-detected). This code does the same thing as calling JS
console.getdimensions(). Since it waits (up to 5 seconds) for a CPR response
from the terminal, this does potentially slow down output, so caveat emptor.

This could be used by a sysop to address issue #529.

Handles integer overflow in the summing of user's credits and remaining daily
free credits.

In a minute, this CPS value will be of more use since it'll be reflective of the user's actual download rate (in characters/bytes per second) instead of just some randomly-chosen numeric constant.