I discovered the first case when FileBase.get_path() failed, but didn't
(immediately) throw an exception. Reviewing the other instances of
JS_RepoertError() calls found several that either reported a garbage (e.g.
NULL) string value or returned JS_TRUE.

The design pattern used a little in js_socket.c probably should be used more:

	if (JS_IsExceptionPending(cx))
		return JS_FALSE;
	return JS_TRUE;

... but that's more of a refactor than I had the stomach for right now.

For 10 years (commit e212e2c5), sbbs_t/console.getstr() has limited length
of string input to the available columns of the terminal.

To fix issue #869, rather than change getstr()'s default behavior, add a new
mode flag: K_LINEWRAP which does not limit the string length input based on
the terminal width (and the current column) (e.g. for use with ;string
commands from the default command shell).

Ideally, I'd like to have a marquee-style option (K_mode flag) where longer
strings just side-scroll to accommodate strings longer than the terminal
width, but in the mean-time, this'll do.

So anywhere we think a narrow (e.g. 40 column) terminal is being excessively
restricted in string input width and starting the input in the first column
is not an option/solution, adding the K_LINEWRAP flag to the getstr() call is
the proposed solution.

For sysops that don't want to use the user's chosen language to auto-load
alternate text strings, they can specify some other filename from the ctrl
directory (so long as it ends in .ini). I wouldn't use text.*.ini however,
since those filenames are assumed to be language translations and will
automatically appear in user_settings.js as a user-selectable language.
text-*.ini would be fine though as an alternate text.ini filename:
not colliding with text.ini or text.*.ini

and not throw and exception. :-(

This was broken in commit 6dbd2fec

Caught by code review.

More method will now throw exception if called without args:
bbs.check_filename(), bbs.logkey(), bbs.export_filelist()

bbs.check_syspass() will prompt for system password if passed null or undefined
value.

Fix (and document) the optional channel argument to bbs.multinode_chat()

Throws an exception now instead of using uninitialized args:

;eval
Parameter(s): bbs.compare_ars()
InternalError: allocation size overflow

Updated JSDOCS for methods (mostly just adding punctuation). Fixed a typo
or two.

Many global functions now throw an exception when null or undefined is passed
as a required parameter where null or undefined makes no sense.
e.g. "Argument #1 is an unexpected 'null' or 'undefined' value"
Example exception: is-a/has-a type functions will still return false when
passed null or undefined.

Changed global function return types:
- write() now always returns undefined
- printf() always returns a string, never undefined or garbage string
- prompt() returns null (not undefined) upon no input (as documented)

sbbs works more like jsexec:
- read(0) now returns an empty string instead of undefined
- readln(0) no longer waits for enter

jsexec works more like sbbs:
- add missing write_raw() global function, alias for write()

Include expected number of argment in "Insufficient Arguments" exception
message.

Update JSDOCS for some global methods:
- file_chmod returns boolean, not number
- flags_str requires a minimum of one argument

New tests to validate expected exceptions and return types based on usage.

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

Looking into potential causes of issue #843, I found several instances where
we call getuserdat() without checking the return value and restoring the
useron.number to the current user number upon error: getuserdat() zeroes out
the user struct/number upon error, a bad API choice made 23 years ago.

Replace those instances with calls to sbbs_t::getuseron() which logs any
open/lock/read failures of the user.tab and does not modify/zero-out the
sbbs_t::useron struct upon error.

For alignment with the text() method and for instances where a script author
doesn't want to load('text.js') or use [bbs|system].text.ID to get a text.dat
string index from an ID.

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.

Apparently JSVAL_IS_STRING() can return true even when argv[1] is out of range
(I guess I assumed it'd alwasy be NULL or VOID/undefined) and this can lead to
crash when calling JS_ValueToString() on it.

This was just a typo which didn't allow the single-file upload xfer prot menu
to be shown.

Actual fix for CID 11447 (previous attempt, commit f50c866f was
insufficient). Thank you Coverity!

Currently, this is a slower way to look-up a text.dat string, but requires no
load/require of text.js and allows for a shorter syntax to get a text.dat
string, i.e. bbs.text("Quit") instead of bbs.text(bbs.text.Quit);

Although the bbs.text() ID lookup is cached, it's only marginally faster than
system.text() ID lookup, which is not cached and about 1/3 the speed of the
other methods of index to string lookup (in the MSVC-Windows build).

... that the user has access to

So we don't have to reimplement this logic in user_settings.js (or
equivalent) any longer.

Helpful for a JS batch file transfer menu

These 2 properties, specifically, could be made writable since
1. smb_t.curmsg is a special element owned by the application, not smblib
2. a special sbbs_t.current_msg_number property could be created/used to
   underlie the bbs.msg_number when there's no open message base (by sbbs).

This might be all that's needed to resolve issue #793

The other bbs.msg_* and bbs.smb_* properties are not so easily made writable,
so hopefully that's not desired.

Not sure how I missed this one, but this file was needed to complete the
'bbs' object changes mentioned in that commit message.

HANDLE_PENDING() macro returns from the calling function (without freeing
allocated resources), so don't use that here.

If an array argument is passed to these methods, the stringified contents of
each array element value will be sent to the remote server after connecting.

This is to support Nelgin's request of sending some strings to a server after
connecting. There's no way to insert pauses between the sent strings or wait
for certain output from the remote - that's beyond this scope/capability.

... as appears to have been the intent

A couple of error paths in expand_atcodes() method could leak heap memory.

For Nightfox's use in DDMsgReader.

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

error: Uninitialized struct member: node.misc [uninitStructMember]

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.

New method: bbs.load_user_text() to load/reload user's language file. The
user's select language file (if there is one) is automatically loaded upon
logon to the terminal server, but if the user changes their language
(e.g. via user_settings.js), we needed a way to force re-load of the language
text. This is the way.

bbs.text() now accepts an optional second (bool) argument that if true, will
return a string from the default language strings (in text.dat), and not a
string from any alternate language files (ctrl/text.*.ini) that might've been
loaded. This allows user_settings.js to always get the name of the default
language string (LANG), e.g. "English".

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