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

Where ever we assign the realloc() result to the same pointer we pass, use this new function instead to eliminate the cppcheck error reported by Nelgin:
Common realloc mistake: 'p' nulled but not freed upon failure  [memleakOnRealloc]

This isn't going to actually solve any memory leaks, it's just good practice for critical error (e.g. no memory error) handling.

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!

Mostly (all?) about unchecked return values. Unexpected failures to read or
write some files could've definitely led to some weird bugs.

Also a bit more constification and cleared up the legacy sbbs_get_ini_fname()
usage: the hostname argument hadn't be used in a long, long time.

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.

Don't return an error if the node#/node.cnf file can't be opened for all uses of load_cfg() except from the terminal server. This fixes #214 for Tracker1

We were just trusting that the error strings would be shorter than 256 (usually), but since we're including paths and strerror() results, we really have no control over the length of the error strings. So enforce some healthy boundaries. This could explain the crashes that Divarin of Mutiny is seeing with SCFG on WinXP or maybe it was the truncsp(strerror()) stuff that was just removed as well. We'll see...

The goal of this commit is that: only modules that either are part-of sbbs.dll/libsbbs.so or need to link with/use that library, will #include "sbbs.h" and thus be dependent on its subsequent includes (e.g. cryptlib.h, jsapi.h). This should mean extdeps.mk can be trimmed way down.

I also removed CVS keyword/comments and trimmed up the boilerplate copyright notice in modified and added source/header files in this commit.

There is no functional change in behavior in this comment.

If jsexec is used for a CGI script and the SBBSCTRL env var was not
set, a warning would be printed (to stderr), even if the -c option
was used to specify the path to the ctrl dir.

get_ctrl_dir() now accepts a boolean argument to specify whether to
print a warning when the default value ("/sbbs/ctrl") is used.
Pass FALSE for jsexec, TRUE for other callers (currently).

not set (or blank), use the default ("/sbbs/ctrl") and print a warning to
stderr. This resolves a FAQ for sysops that struggle with setting the SBBSCTRL
env var, but do have sbbs install in /sbbs or a symlink from /sbbs to where
sbbs is actually installed.

Note: this function is different than the one previously defined in getctrl.c
but never used. If/when we ever really need to support PREFIX, then perhaps
we'll use that one (which copies a string to a buffer).

(i.e. *nix) - I guess nobody really uses this utility.
Incremented version to 1.02.

Fixed msvc6 warnings and errors.

by properly const-ifying the appropriate functions and variables.

Not yet tested on Win32