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

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

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.

Mainly capitalization, but some typos and added details. 

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

has detached from the queue.

declaration

Use this in place of JS_GetPrivate() in native class methods that need the
class instance's private data pointer and will do bad things if that pointer
points to something other than what is expected. mcmlxxix (matt) discovered
that using Object.apply(), you can invoke class methods where the 'this'
instance is a different class. This would result in
"Internal Error: No Private Data." or a crash.
So now, gracefully detect this condition and report a meaningful error:
"'<class-name>' instance: No Private Data or Class Mismatch"

Also, important to note: if the method uses JS_THIS_OBJECT to get the JSObject*
to pass to JS_Get*Private, then it must do this *before* it calls JS_SET_RVAL.

From jsapi.h:
 * NB: there is an anti-dependency between JS_CALLEE and JS_SET_RVAL: native
 * methods that may inspect their callee must defer setting their return value
 * until after any such possible inspection. Otherwise the return value will be
 * inspected instead of the callee function object.

The js_crypt*.c files still need this treatment.

HANDLE_PENDING() contains a return, so it's theoretically possible that the
memory allocated by the previous JSVALUE/STRING_TO_... allocation could
be leaked. So now we pass an optional pointer to HANDLE_PENDING() which will
call free() on it if it's not NULL, and then sets it to NULL for good measure.

function where the error is being reported from. So the WHERE macro now
contains the __FUNCTION__ "macro" and the various js*.c files that use the
WHERE macro to report errors had to be updated too.
Also, the 'access' argument is now being passed as a signed long rather than
unsigned long. Status/return values are often passed in here (e.g. from smblib)
and may be negative. This argument was being displayed with %ld but wasn't
being passed in as a signed value, so on 64-bit long systems, negative numbers
were just printed as large (4M+) numbers.
Also, no need to call getfname() in errormsg() since this is embedded in the
WHERE macro (since 2009).

your return value anyway.

item enqueing stuff which has been carefully preserved and equally carefully
never used.

call free() when processing for a js_peek() call with the old manual
serialization.  Obviously, it hasn't been used since the update to the JS
internal serialization stuff, and the new fix doesn't need it.

js_peek() calls js_decode_value() which would free the data for successive
js_peek() or js_read() calls to choke on.

Thanks for the report MCMLXXIX!

Fix bug where multiple named queues with the same name could be created if
their name is specified with more than 128 chars.

NULL because the get function is called on the prototype which isn't
constructed (via the constructor).

resolve callbacks.

Since this requires a context in the same runtime and we're not sharing one big
runtime (yet), we'll copy it out of magic JS land and into more sane normal
heap land and JS_free() immediately.

This should fix teh Windows crash on queues that digitalman was seeing (and
the leak he added to fix it).

a heap assertion (with jsexec/ircd.js).
I'm not sure if this is now a memory leak or what, but Deuce needs to take a
look-see tomorrow.

The dest6 test to check if the date passed though safely seems to be broken
as it actually does pass through and work but the comparison doesn't.

functions when an excpetion is pending.

Some work still needs to be done on js_msgbase.c,  js_user.c, and mailsrvr.c

Only js_ValueToStringBytes() still leaks.

(Everything still broken)

      on the floor of Deuce's computer room
Cyan: Rob's on his way
* Deuce throws his coffee on it.