POSIX states that the return value of isdigit(): "shall return non-zero
if c is a decimal digit; otherwise, they shall return 0."
Thus the form:
ok &= isdigit(x)
is invalid since the runtime is not required to return 1.
This bug was observed on Debian 11 while using the clang toolchain.
In that environment, isdigit() returns 2048 for a positive match.
During testing in a sandbox environment, xlxd crashed in
CG3Protocol::Close(). The root cause was dereferencing
m_pPresenceThread when the object had never been initialized.
In this case an error occured during ::Init() which set ok=false,
so the initialization of the threads was skipped.
This commit does 3 things:
(1) Default initializes the thread pointers to avoid the crash.
(2) Wraps the thread allocation with try/catch since std::thread can
throw.
(3) Does some light cleaning in ::Close, e.g., converting NULL to
nullptr.
This patch reverts the change done on v2.4.1, so that streams are closed immediately as it used to be (instead of relying on CheckStreamsTimeout) but fixes last packets sent back to sender, by doing basically what was already done before but on proper order to avoid the issue.
Relying on CheckStreamsTimeout actually introduces a problem: transmitting client gets "mute" for 1.6 sec. after each transmission, this means that if a 2nd client starts transmitting within this time frame then the "mute" client can't listen the beginning of the 2nd client transmission, the problem is even worst (i.e. critical) for DExtra because the "mute" client will not be able to get the header packet of the 2nd client transmission and this means that whole transmission is lost - this renders DExtra almost unusable on v2.4.1 unless all clients take special care about spaces between transmissions.
depending on the number of dplus clients connected on the reflector, in some cases (for eg. with 3 or 6 clients connected) only one client could actually get lots of header packets and the other clients get none
Maximum size of ICMP packet is 64k while buffer allocation was UDP_BUFFER_LENMAX, while read was up to 64k.
This will cause a crash on read in the subsequent read for packets with length greater than UDP_BUFFER_LENMAX via a buffer overflow.
