• src/sbbs3/zmodem.c

    From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Friday, September 26, 2025 14:17:14
    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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tuesday, December 02, 2025 15:29:39
    https://gitlab.synchro.net/main/sbbs/-/commit/ab995dd1db4530b0f3bd90ab
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Fix parity inversion in comments

    Even parity means that the high bit is *set* (when necessary) to insure an
    even number of set bits in every sent byte. Odd parity is the opposite.
    I had this backwards in my comments.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Friday, March 06, 2026 21:58:36
    https://gitlab.synchro.net/main/sbbs/-/commit/02f0ebb9bd66b1c1ad3873b5
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Add some more log messages to zmodem_get_zfin()

    to try to root cause 'OO' transmission issue (observed with Chuck Forsberg's rz).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Friday, March 06, 2026 22:30:03
    https://gitlab.synchro.net/main/sbbs/-/commit/a3b7cff7fa45e4e5fb7a185f
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Call zmodem_flush() after sending the 'OO' after a ZFIN

    Chuck's rz (readline) waits indefinitely for these two O's.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Sunday, March 15, 2026 16:01:53
    https://gitlab.synchro.net/main/sbbs/-/commit/87b7d946c0ab40a5a20343ee
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Remove vestigial int32_t casts truncating file sizes in zmodem_recv_files()

    Three comparisons between l and bytes cast bytes to int32_t, silently truncating file sizes > 2GB. Both variables are int64_t — the casts
    were left over from the 887147a69c "64-bitify" conversion where
    long/ulong became int32_t/uint32_t before being later widened to
    int64_t.

    Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

    ---
    ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, March 15, 2026 16:24:40
    https://gitlab.synchro.net/main/sbbs/-/commit/c787342dc9ae4fd3005d224e
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Fix API violation in zmodem_recv_bin32_header()

    Introduced in commit 83b672364, Claude caught this:

    zmodem_recv_bin32_header() returns TRUE on error (zmodem.c:1200)
    When zmodem_rx() returns an error (c < 0) during CRC-32 header reception, the function returns TRUE (success) instead of FALSE. The subsequent CRC check will almost certainly catch this, but the function's contract is violated.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net