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.

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.

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.

there are still other undocumented fields/properties, but this one for sure
was missing.

Nelgin reported a weird error with a failed very large allocation for the
base/code argument to the FileBase constructor. There's no good reason
these strings were heap-allocated in the first place, so just change to
use a stack allocated variable instead. I don't know why this would fix
anything, but at least there's one less heap allocation and potential
for memory leak here.

Fix 2 bugs in js_update_file():
1. missing parenthesis (really?!? Caught by Coverity - sigh) in last
commmit caused attempt/failure/error to remove file after making any
updates. The removing is only supposed to happen when its necessary to
remove and re-add the file to the filebase (e.g. updating extended
description or auxdata).
2. Wrong filename used in 'removing' exception string.

And really, more importantly, the msg header field_list array length would
always be interpretted as 0-length!

... introduced in commit 54523145

As was discovered as part of investigation into issue #769, a JavaScript
could crash SBBS (cause a segfault) due to a NULL pointer dereference when
the script passes 'null' to native JS functions where an object is expected.

The issue raised was with console.gotoxy(), but it turns out that *many*
Synchronet native JS functions would call JSVAL_TO_OBJECT() and then, without
checking for NULL/nullptr, pass its return value to JS api functions such as
JS_GetPrivate, JS_GetProperty, JS_GetClass, JS_ObjectIsFunction,
JS_IsArrayObject, JS_GetArrayLength, JS_DefineProperty, JS_Enumerate, etc.
All of these JS API functions dereference the passed object pointer without
NULL/nullptr checking.

The fix here is to either call JSVAL_IS_NULL() or JSVAL_NULL_OR_VOID() and
if true, not call JSVAL_TO_OBJECT() and/or check the return value for the NULL
value before using as an argument to any other JS API functions.

To support the full 32-bit range for things like dates/times, and message
numbers (!).

This should fix issue #732

Though dates beyond Feb 7 2106 are definitely going to still be an issue. I'll
definitley look into solving that by the the 2100.

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

... in malloc error reporting messages

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.

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!

A bunch of possible (but often, not really) use of undefined values.
Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets).

Other than some added diagnostics upon some of these unexpected syscall
failures, there should be no change in behavior from this commit.

Mostly just bitfield->bit-flags.

No functional change, just a little clean-up.

... rather than just failing silently with a special return value
(e.g. false).

So use js_argc() to report an error if there's fewer than 1 argument, but
don't just fail silently when 2 arguments are provided.

... rather than just return false.

This will make debugging this type of issue much easier in the future.
sendmail.js was allowing empty recipient_list array arguments and the MsgBase
.status was 0 and .error just an emtpy string - unhelpful.

Mainly capitalization, but some typos and added details. 

js_open() sets the rval for the context (e.g. to JSVAL_TRUE), so we need to set
it back to JSVAL_FALSE for failure conditions. Otherwise, the methods always
return true even upon (save-msg) failure.

The other msgbase property values are stored in the smb.status or other private_t members which retain their value when the message base is closed, unlike the 'first_msg' property which required a read of the message base index to get the value (and that doesn't work when the message base is closed, so would return 0).

for deon (ALTERANT)

This restores the ability for JS MsgBase() to be used to create the
initial mail message base properly, if needed.

This means that the 'subnum' should now be equal to scfg.total_subs
when referencing an arbitrary SMB via path (not in the configuration).

Before commit 5da26eca, you could pass Msgbase() the path to an SMB
on the disk and open() it, no configuration needed. As of 2 years
ago, I broke that, and passing a path to an SMB would open the "mail" base
instead - most unexpected. This is a feature of smb_open_sub() which we
switched to using (from smb_open()), so go back to using smb_open() when
an unrecognized code is pass to the constructor.

This has the negative consequence that the "mail" base can't be created
via JS. Probably should fix that.

This is what was causing the 'is_utf8' message header property to be created as a Number instead of a Boolean.

To fully support files > 4GB in size in file bases, credit values larger than 32-bits must be supported too.

There's a couple of todo comments/items included in this commit, but that's mainly to do with messages (which don't really have costs anyway).

The main thing to deal with now is the fact that users can't have more than 4GB in credits in the first place! That's got to be fixed next.

When setting the value of a message's 'can_read' property, ignore the PRIVATE message attribute (which is sometimes set in FTN netmail messages) since it's assumed all messages in the mail base are private, no special destination (to) name matching is needed here.

This only popped up recently via msglist.js because of the recent addition of checking each messages's 'can_read' property.

As reported by <Diehard> via IRC PM.

Underscores are more JS friendly (and correct).

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

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

Advertise the system's QWK-ID (a.k.a. BBS ID) in exported echomail messages. This will allow correlation of avatars that were imported via SYNCDATA carried via QWKnet (e.g. DOVE-Net) with messages imported from those same BBSes via FTN.

The alternative was to have SYNCDATA Avatar messages include all the AKAs of each BBS (in the body text), but that was looking like a rather complicated solution. This approach (the BBSID kludge) seems a much simpler solution.

I still need to implement the JS side of this solution however (for avatar lookups using the FTN BBSID), but this was the first important step.