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.

Then, add JSDOC support to crypto class constant objects.

Also, since crypto stuff is almost half of all the docs, move all
the crypto classes and objects to the end. It would be nice if these
massive lists were hidden by default line the menu tree at the start.

corresponding *_net_addr field is present (not NULL).

Allow an added or modified message header to have to/from/reply-to "net type" values of NET_NONE. This is a weird scenario, but it is technically possible (e.g. for nntpservice.js) to save a message with a to/from/treply-to "net address" header, but an associated net-type of NET_NONE. By saving the net-type NET_NONE, when saving a modified header, if the associated net address header field value cannot be parsed into a valid network address, there won't be any error reported, e.g.
Error -110 adding SENDERNETADDR field to message header

header field) when saving a message using the MsgBase class.
A similar problem existed with REPLYTOLIST/RFC822REPLYTO, but was not actually
observed.
Since the following header fields were not populated in the msg header
"field_list", if they existed in a message header that was modified using
the MsgBase class, they would be lost:
- RFC822TO
- RFC822CC
- RFC822ORG
- RFC822REPLYTO
- RFC822SUBJECT

It would create 3 0-byte files (*.shd, *.sdt, *.sid), but more is actually
needed for a message base to be "created" (i.e. a call to smb_create()).
So, MsgBase.open() now uses smb_open_sub() rather than smb_open() to initialize
theSMB  status fields with the proper default values (based on the sysop
configuration) and calls smb_crate() if the header file is empty.
Yes, normally, SCFG creates message bases, but it shouldn't have to
(e.g. a fresh install on *nix, doesn't actually start with any files in
data/subs) and now that we have JavaScript-based message lister/readers, we
really needed this support.

(SMTPREVERSEPATH a.k.a. "reverse_path") if it didn't already have one.
That's because smb_getmsghdr() will point the msg.reverse_path convenience
pointer to the from_net_addr if there was no explicit reverse-path (e.g. RFC822's
"return-path" header field). This could manifest itself in *any* change to a
message header via JS failing with an "illegal header length increase" error if
the added header field just happen to put the total header length over the
allocation threshold of the pre-existing msg header.

Fix: only model a msg header "reverse_path" property if the header field
actually existed (not based on the SMBLIB convenience pointer).
When the expand_fields option is used, the old behavior remains but expanded
headers cannot be written back to the base, so no harm there.

Reported by Coz in #synchronet from failed runs of scrubmsgs.js. Thanks!

"dump" to an array of strings using the (new) smb_msghdr_str_list() SMBLIB
function. The message header passed must've been previously returned from
the get_msg_header() or get_all_msg_headers() method.

A similar dump could be constructed from the header properties, as available in
JS, but that would be inconsistent with other msg header dumps and likely lack
header fields or details available from the lowest level dump method provided
in SMBLIB.