https://gitlab.synchro.net/main/sbbs/-/commit/57e0d22816044e34efcf7e0d
Modified Files:
src/sbbs3/zmodem.c
Log Message:
Resolve newly added MSVC warning

warning C4244: 'return': conversion from 'uint64_t' to 'unsigned int',
possible loss of data
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d2cd0a651384b4c6f9ccfd3a
Modified Files:
src/sbbs3/zmodem.c
Log Message:
Ok, so the real issue Coverity has is the tainting of nX.

Have zmodem_recv_nibble() explicitly range-check all values, and
handle negative values. If this remains an issue, it can be
untainted with range checks on each nibble, but let's not go there
to start with.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/35f2ec2f73a22d3b7702787a
Modified Files:
src/sbbs3/zmodem.c
Log Message:
So, Coverity knows that won't happen, so that just creates a new issue

Try untainting it in recv_hex... if that doesn't work, I'll just
have to ignore it I guess.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8be9b414e85a30b6da2cdb06
Modified Files:
src/sbbs3/zmodem.c
Log Message:
Yep, Coverity knows those won't do anything.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f5db57c486e22411d71e861c
Modified Files:
src/sbbs3/zmodem.c
Log Message:
Suppress Coverity overflow issue.

This can't actually happen.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/430f50363dcd4db76e06906d
Modified Files:
src/sbbs3/zmodem.c
Log Message:
So, Coverity knows that won't happen, so that just creates a new issue

Try untainting it in recv_hex... if that doesn't work, I'll just
have to ignore it I guess.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/1af0752917c8a7c0d331582d
Modified Files:
src/sbbs3/zmodem.c
Log Message:
Handle rx'd hex headers terminated with "\x8D\x8A" (i.e. "\r\n" with parity)

Although this sequence doesn't really make sense since there's an odd number
of set bits in 0x0D and an even number of set bits in 0x0A, setting the
parity flag in each byte is just wrong, this is how Tera Term 5.5.0 terminates its transmitted ZMODEM hex headers:

ZShHdr() from Tera Term's zmodem.c:

zv->PktOut[zv->PktOutCount] = 0x8D;
zv->PktOutCount++;
zv->PktOut[zv->PktOutCount] = 0x8A;
zv->PktOutCount++;

Although this code does appear "inspired" by Chuck's rz/sz source, they failed to duplicate this logic from Chuck's zshhdr() from zm.c (with added comments):

s[len++]=015; // 0x0D
s[len++]=0212; // 0x0A

Chuck's zrhhdr() function handled this CR parity-oddity on the receive size (using octal constants as he did):

switch ( c = READLINE_PF(1)) {
case 0215: // 0x8D
/* **** FALL THRU TO **** */
case 015: // 0x0D
/* Throw away possible cr/lf */
READLINE_PF(1);
break;
}

... so we'll do so too for bug-compatibility with Chuck Forsberg (RIP) and
T. Teranishi.

This resolves issue #595

Incremented version of this file to 2.1
--- SBBSecho 3.29-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)