This resolves the conflict with MSG_HOLD definition in socket.h on MacOS:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/socket.h

And hey... [NET]MSG_HOLD isn't actually used anywhere? What's up with that.

This could use more cleanup (e.g. instances of "MSGERR:") and in the summary
report there are still mentions of "message" after scanning a file base.

Make behavior consistent with smbutil and fixmsb.

Recently started truncating trailing whitespace from sender/recipient names
before calculating the CRC value (similar to what we do for message subjects
as of a year ago). To suppress errors when evaluating messages (with trailing
whitespace in sender or recipient namems) created or imported before this
change, use this new -N option.

the Subject CRC calculation was changed in May of 2022 (trailing whitespace is
removed prior to calculation), so messages imported before this date/revision
of sbbs might be detected as having an invalid/mismatch Subject CRC. This -S
option can be used to suppress such errors (for Keyop).

Don't support /option syntax any longer in non-*nix builds (just -options).
Options are now case-sensitive (i.e. -S and -s are different options).
Bump version to 3.20.

[s]printf format fix-ups

... in debug print statement (MD5 hast decoded/printed as SHA-1 hash).

Reported by Nelgin running gcc version 11.2.0 (Ubuntu 11.2.0-19ubuntu1)

Addresses CID 350318 

This looks like a 20-year-old copy/paste bug. CID 33168.

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

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

The inferred message type should match the stored message type. Confirm that.

Apparently some USENET articles are >= 1MB these days. Thanks Coz.

hour in the future. This allows for small adjustments in the local system clock.

(unsigned-long to ASCII with commas) in rev 1.68 (addressing warnings).
A size_t (i) can't go negative. Duh.

reported as "Duplicate index offset", so overlapping headers means the
index offset must not be an exact duplicate, so we don't report the same
corrupt message parameter (its offset into the header file) 2 different
ways.

This has not actually been an observed problem, but I just realized while
working on smb optimizations that this condition would not be reported by
chksmb.

warning: ‘*’ in boolean context, suggest ‘&&’ instead
note: ‘sprintf’ output between 5 and 132 bytes into a destination of size 128

prompts with the conditional beep enabled only with the '-b' option
(silent by default). Thanks to Nelgin.

syncprog and the commit log again).

for very old message bases).

files don't correlate correctly with the data (sdt) or hdr (shd) files.
Report errors if either the data or hdr file are not a logical length
(e.g. not evenly divisble by the block length).
Report the oldest message (in days) in the msgbase, from import date/time.

ToDo: report messages posted/imported (or written) in the future
ToDo: keep the stats in an array for sensible clearing and reporting

as errors.

header records (index with the same message number points to a different
message header).

There (will be) the possibilty to cast mutliple votes in a single vote-msg
(ballot), when multi-choice polls are introduced later. There were just too
many things call vote/votes and it was getting confusing in my own head. So the
msg type for messages that contain votes is now "ballot".

The beginnings of an SMB-based voting system - very experimental:
The concept is that a "vote" message can be used to reply to:
1. A normal message, as either an upvote or a downvote, ala social media
2. A poll, polls can either allow a single choice answer or multiple answers
Vote messages won't be visible as normal messages (e.g. when reading messages
online) and SMB processing software (e.g. SBBSecho) should ignore these
messages because they have no body text.
Polls are going to need more work, but the idea is to have the poll question as
a single (newly defined) hfield and the possible answers as dfields.

I've likely broken something though, so if you see weird behaviour with
extended ASCII, let me know please.

This is *likely* to break the Win32 build and even when the macros are
specified in xpdev, I doubt Microsoft has added support for the 'z' size
specifier used in smblib/smbadd.c we'll likely need a SIZE_T_SIZE macro
that is "z" on C99 systems and "ll" or "64" or whatever it is on Win32.

Or maybe a whole slew of complete SIZE_T macros since the 32/64 but thing
and the max file size thing may actually need the full format specification
to be in the macro... "zu" on C99 platforms and whatever magic Microsoft
needs there.

SENDER field with trailing whitespace removed.
Added hash file validation (checks message numbers, times, source type values).

(subjects can/should not be used for dupe message checking).