... when current timezone is negative offset from UTC, but not a US time zone,
the default should be "No".

DDMsgReader bug fix: In the scrolling message reader interface, it now exits on user input timeout (as it should). This should fix issue #844, reported by Keyop

Closes #844

See merge request !483

DDMsgReader bug fix: In the scrolling message reader interface, it now exits on user input timeout (as it should). This should fix issue #844, reported by Keyop

Presumably it's because I'm not using std=gnu11 or whatever

Use the same hack as for strerror_r()

The non-standard strerror_r() is glibc specific, musl doesn't do
that.  It *appears* that __USE_GNU implies glibc.

Looking into potential causes of issue #843, I found several instances where
we call getuserdat() without checking the return value and restoring the
useron.number to the current user number upon error: getuserdat() zeroes out
the user struct/number upon error, a bad API choice made 23 years ago.

Replace those instances with calls to sbbs_t::getuseron() which logs any
open/lock/read failures of the user.tab and does not modify/zero-out the
sbbs_t::useron struct upon error.

... since all (almost all) callerd do a config check first.

Also, some callers of openuserdat() were expecting -1 on failure (always).

Functions that returned the return value of openuserdat() upon failure, now
return USER_OPEN_ERROR instead, to be consistent.

A copy/paste from websrvr.c

... that is working (for me at least) to auto load/rerun sbbs

This needed a custom solution (not errprintf) since the filename is passed-in
is likely from dynamically allocated memory, so a pointer comparison isn't
enough - and we don't get the function name.

This is a solution for issue #842, but only for messages posted/sent from the
terminal server using built-in functions and not via JS or other means. A more
universal/generic solution would be nice (beyond just always storing message
headers and bodies in UTF-8), but nothing has come to mind.

This reverts commit 79fa3c0b.

Differently than all other types, the length must be set before
parsing because the BPP does not contain the length data, instead
the length is specified by the message definition.

The expectation is now that there will be a single copy of SSH BPP
contents and arrays and buffers will be pointers into that.

This avoids another allocation/free requirement.

All consumers are expected to only #include deucessh.h now.  Individual
headers should not be included.

So require(..., 'node_status') instead. The function we actually use here.

and we weren't using that function here anyway, so require(..., 'node_status')
instead.

Looks like this feature (commit d661427e) never really worked correctly
since it counted the files removed from each sub-dir and then stopped deleting
when the count reached the number of files in the base directory. This was
done to accommodate the 'keep' feature (part of previous commits).
So make 'keep' check conditional on it being non-zero and just don't ever use
a non-zero keep value with a recursive delete and we should be good! :-)

This fixes issue #841

part of fix for issue #619

Part of solution for issue #619 (for the web server)

Part of solution for issue #619 (for the mail server)

For alignment with the text() method and for instances where a script author
doesn't want to load('text.js') or use [bbs|system].text.ID to get a text.dat
string index from an ID.

(which might be UTF-8 encoded). This works-around the problem that Accession
reported in #synchronet with my reply to a UTF-8 encoded message using a CP437
terminal which resulted in a message body that was UTF-8 encoded but a message
subject that was CP437 encoded. This mix of encodings is not supported by FTN
standards.

This is just a work-around since if the user modifies the subject the result
could still have the CP437 unside-down question marks (indicating
non-translatable UNICODE chars) and those should be converted to UTF-8
chars when going out on FTN or being stored in the message base. So there's
still a bug here somewhere that I need to look into more.

- when converting from CP437 to UTF-8
- when reading from RESULT.ED drop file

This effectively limited message subjects in some instances to 69 chars
instead of 70. This bug was caught while debugging a replied-message subject
conversion from UTF-8 to CP437 issue reported by Accession.

We have to use load() (rather than js.exec) to invoke str_cmds.js so that an
exit() will actually exit. Since load() automatically does the mods vs exec
directory search-dance, that simplifies the code in default.js a little.
I'm not sure exactly why I originally chose to use js.exec() over load() for
invoking str_cmds.js, but for this feature, we need load() so let's go with
that for now.

I did encounter an issue (issue #840) while originally trying to make this
work with the original code that called js.exec(), but just punted and went
with load() instead. Perhaps if we fix issue #840, we can revert default.js
back to using js.exec() (but why we would need/want to, I'm not sure).