This change needed to build dosxtrn.exe (again).

Now IS_WHITESPACE() will return true for that char and this allows things like truncsp() to truncate trailing white-space (e.g. from a FILE_ID.DIZ), even if it contains a terminating 0xFF character for some unknown reason.

Caught by CID 331001

The use of SAFECAT() with a typecast to a pointer is not going to work as expected. This change broke line-based telnet-gateway functionality (unconfirmed, but pretty obvious).

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

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.

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

expands to "ld"/"lu", respectively since off_t is a long (not an int):
examples:
ftpsrvr.c:1374:77: warning: format '%d' expects argument of type 'int', but argument 6 has type 'off_t {aka long int}' [-Wformat=]
   lprintf(LOG_WARNING, "%04d <%s> !DATA cannot send file (%s) with size of %"PRIdOFF" bytes"
websrvr.c:6063:45: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'off_t {aka long int}' [-Wformat=]
   lprintf(LOG_INFO,"%04d Sending file: %s (%"PRIuOFF" bytes)"

so put the 64-bit integer stuff in an #ifndef __MSDOS__ block to enable the
build to succeed.

It's not unlikely that any utilities using SDL will have new issues... you
may want to hold off on updates for a bit until this settles unless you
don't use SDL mode.

if (fg)
	FREE_AND_NULL(fd);
else
	FREE_AND_NULL(bg);

HEX_DIGITS() and DEC_DIGITS()

and no actual observed problem.

is defined - resolves gcc warning in ftpsrvr.c.

unsafe strcat() usage (potential buffer overruns).

CR or LF, just a convenience wrapper for SKIP/FIND_CHARSET(p, "\r\n")

ala Synchronet text.dat) by default and octal format only if
C_UNESCAPE_OCTAL_SUPPORT is defined.
\X## is no longer supported (must use the C-standard \x##
Only 2 hex digits are now supported, longer streams of valid hex digits will
not be parsed as a literal character (unlike the C standard)

along with the standard Control Character 'Symbol" for each in a comment.

Whatever made us do that seems to not be happening with --std=c99.

build error) - conflict with definition form vadefs.h.

and uintmax_t... them suckers will be big enough you betcha.

an unsigned long can hold any pointer (Should fix builds with old Borland
compilers - ie: sbbsctrl)

doesn't like it when you don't.

specs.