Was terribly broken.

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

Non-poll used the wrong value for calculating the high socket (which
is ignored on Win32, the only non-poll() user), and the socket was
being set in the wrong union member.

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

js_callback_t was not being properly retreived.

This appears to work and the event handler *should* work on other
event types already.

Note, this is *nix-only due to the use of poll().  select() will
need to be used for Windows to keep XP compatability.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

<@Deuce> Just saying that if someone does the work of exit_code = {thing: function(x) { return secretsauce }); exit(); they should get away with it.

Don't use the "exit_code" property value as the return value of js.exec() unless it's a number. As reported by mlong (thanks).

Also, "exit_code" was being set to null (instead of void/undefined) in js_PrepareToExecute(). I think this was just an oversight or typo by Deuce from his commit of 5 years ago (f3256d81). Since we're comparing exit_code with JSVAL_VOID in other places to determine if it was actually set, this appears to be a long standing bug.

Store all on_exit() strings in the global scope, execute them
one scope at a time with scopes ordered in reverse order of
first call to js.on_exit().  Within a scope, they are ordered
last string first.

Copy/paste without the update required a single character to have
seven different values... which is unlikely to actually happen.

Have js.on_exit() throw an exciption with a useful(?) error when the
scope already has private data, and that data is not an on_exit list.

This fixes #182.

specially, just pass them on to the script as-is. Included a JSDOC note about
the use of js.exec.apply() to pass a variable number of arguments (ala execv).

Thanks Tracker1 for the pointer to 'spread' which led me to function.apply()
and the JS-standard method of achieving the result I needed with this
enhancement.

I still think that a script that calls exit() is unlikely to expect non-string
arguments in the first place, but if we don't need special case behavior, it's
better not to add it and keep the behavior consistent with load() and
require(). That was the decision of the executive board anyway. :-|

script are arrays, pass each element of the array as a separate argument to the
child script. This allows one script to generate a variable-length list of
arguments to be passed to another.

Improve "script missing" error reporting in js.exec().

not v3.16.

child scope.

A child of the parent scopes js object can't do on_exit() stuff properly
due to the missing private context.  Create a new JS object in the child
instead.

We also need to copy in the js.load_path_list array contents since we don't
want the child changing the parent by accident.

exit_code, and don't throw the exception in the caller.

Remove support for js_scope == scope.  It sorta defeats the whole purpose
of js.exec().

This allows executing a new script in a specified scope, much like load().
There are important differences however...
1) js.exec() *must* specify a scope.
2) js.exec()d scripts can call exit() and their handlers are ran then,
   rather than when the parent script exists as in js.load().
3) The js object is installed in the scope with the real JS object as the
   prototype.  This generally shouldn't be an issue, but if you're doing
   strange things, stranger things may happen.
4) As part of #3, the exec_path/exec_dir/exec_file/startup_dir/scope
   properties of the JS object represent the new script, not the calling
   one.
5) js.exec() only searches in the passed startup dir (if specified) and the
   current js.exec_dir path.  It does not search the load paths or the mods
   directory at all.

This API is also subject to change.

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.

When checking the terminated value, check all parents until you either find
one that is TRUE, or run out of parents.

Do *not* go up the chain of parents when *setting* terminated.  Background
threads still can't set it (TODO?).

scripts global scope (as opposed to js.global which is the instance global
scope), and having exit() define exit_code in js.scope instead of js.global.

This also sets exit_code in js.scope to null when preparing to execute a new
script.  If a new script starts in the same scope as an old one, the old
exit_code value will be destroyed.

This should only impact scripts where js.global != js.scope (bbs.exec()ed,
and mailsrvr)

that MSVC RTL functions will not terminate the program (e.g. jsexec, sbbsctrl)
if an invalid parameter is detected (e.g. unsupported format specifier in call
to strftime()).

counter/limits as branch counter/limits.

slightly improved JSDOC descriptions.
Updated JSDOC description of the 'js' object to be more general.