See if this resolves rjwboys reported error:
threadwrap.h:204:42: error: expected expression before ‘do’
 #define protected_uint32_init(pval, val) atomic_init(pval, val)

This option fixes the fact that the following two lines sometimes
place the variables in different scopes at the top-level of included
scripts:
var x = 1;
y = 2;

I plan to use this to experiment on if this is what's causing much
of the remaining scope chain weirdness... it certain explains some
things we've been seeing (and possibly even things like the METHODJIT
issues DigitalMan saw yesterday).

Enabling in sbbs/jsexec is a much bigger lift, but this change may
end up being all upside... the docs have suggested this option always
be set since it was originally introduced, and now that I understand
scopes better, it's pretty clear why that is.

METHODJIT (JägerMonkey) is doing weird stuff with xtrn_sec.js when
enabled, so don't introduce that noise.

This allows the services thread to terminate correctly.

Sent to terminal user after successfully sending netmail:
- InternetMailSent
- FidoNetMailSent
- QWKNetMailSent

As requested by Keyop in irc.

This should fix the recent JSDoor build issue introduced.

JavaScriptOptions bit-field can be set in sbbs.ini and jsexec.ini to over-ride the default JS compiler options which have been changed from 0 to (options previously only used by JSDoor):
JIT | METHODJIT | COMPILE_N_GO | PROFILING

* JIT - TraceMonkey
* METHODJIT - JägerMonkey
* COMPILE_N_GO - compile-time scope chain resolution of consts
* PROFILING - Choose between TraceMonkey and JägerMonkey at compile-time based on profiling results

Other options available but not enabled by default:
* STRICT - warn on debious practice (i.e. similar to "use strict")
* WERROR - convert warnings to errors
* VAROBJFIX -  use last object on scope chain as the ECMA 'variables object'
* RELIMIT - Throw exception on any regular expression which backtracks more than n^3 times, where n is length of the input string
* ANONFUNFIX - Disallow function () {} in statement context per ECMA-262 Edition 3.
* METHODJIT_ALWAYS - Always whole-method JIT, don't tune at run-time.

Also:
- Fixed JS warning string formatting (missing space separator).
- Removed an extraneous new-line in lprintf() call in mailsrvr.
- Added basic assertEq() global method to jsexec, required when running SpiderMonkey test scripts.

The file attachments, when MIME-encoded, already include a MIME Content-type
header field, so don't send another. This should fix issue #233.

Since the filename is in the subject, we can't allow the user to change the subject (duh). Also, don't bother with the "Fwd:" prefix thing as that could potentially cause problems in other places where the filename (only) is assumed to be in the subject.

Also, make sure to create the destination directory when moving file attachments. These changes fix issue #230 reported by Keyop.

I noticed "DAILY ... Semaphore signaled" in the event thread log output. Now fixed.

Documented here: https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_05.html#tag_02_05_01
This provides the best chance at read_raw() reading from the right
location and updating the file pointer as expected while avoiding
behaviour which is explicitly undefined by POSIX.

There were 2 bug identified by issue #230:
- the "Fwd:" prefix being added to the message subject was being treated as a filename. I first thought to just remove this subject tag, but then thought it best to just ignore obviously invalid filenames in the subject in the first place.

- when forwarding files to a netmail address, the 'to' extension (user number) is 0, so the file will be in the data/file/####.out directory of the sender instead.

We have 4 places (at least) where the message subjects are parsed and only one of those places currently supports quoted filenames (e.g. with spaces in them) and some of the others (e.g. QWK) don't support multiple filenames at all. That should be fixed.

The service clients count is now a protected int, so deal. On Windows, this was resulting in the "total" and "served" values logged as 4294967295.

Caught by Coverity - ftell[o] can return negative.

This function is the fastest file-copy method (or should be), but does not have any progress indication.

Caught by Coverity.

Appear to have been possible (to crash) by using a malformed text.dat file.

Nobody's checking the return values anyway.

Caught by GCC.

Caught by Coverity.

Check return value from read().

Mostly in error-paths.

Add the "two or three lines" that Deuce said were needed to restore this functionality.

Also got rid of some now unnecessary (void) protected_*int* return value ignoring warning-suppressors.

Interesting, this is how this code worked back in 2005, but was changed without a good description of why:
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/xmodem.c?r1=1.15&r2=1.16

This addresses the anonymous SyncTERM bug report:
https://sourceforge.net/p/syncterm/tickets/46/

Thanks, whoever that was. :-)

Fixes last commit, which could cause infinite hangs on certain requests.

Should fix #223
Introduced in d56ba01f which likely fixed some stuff on the wiki.

Issue introduced in previous commit to this file. The name arg(s) comes before the address arg(s).