https://gitlab.synchro.net/main/sbbs/-/commit/cf91dbd29c8cb87eeb272151
Modified Files:
docs/sexyz.txt v322_new.md src/sbbs3/sexyz.c zmodem.c zmodem.h
Log Message:
sexyz: remove Escape8thBit, and stop advertising ZMODEM's ESC8 option

Setting Escape8thBit=true made sexyz advertise ZF0_ESC8 in its ZRINIT,
asking the remote sender to escape every byte with the high bit set --
which sexyz then could not decode, logging "Illegal sequence: ZDLE nnn"
until the session timed out. It also ignored the flag when sending, so
it never escaped for a peer that asked. The option has been advertised
since 2005 and implemented in neither direction since the code was
imported in 2003.

There is also nothing to implement it against. ZMODEM.DOC names ESC8
once, in passing, and never states how a high-bit byte is escaped, where
it gives ESCCTL a full paragraph. The two programs that do implement it consequently disagree: Omen's DSZ quotes a high-bit byte as 0x0E
followed by the byte with bit 7 cleared -- Kermit-style prefixing, and
it switches to an unpublished frame type to do it -- while zmtx/zmrx
2.04 sends ZDLE and the byte XOR 0x40. Advertising the bit commits us
to whichever encoding the peer happens to have chosen, and we cannot
satisfy both. Rob's call, and the right one: we have lived 21 years
without it.

Drop the ini key, drop the advertisement from zmodem_send_zrinit(), and
say at both remaining sites why the flag is inert. The peer's request
is still recorded from its ZRINIT for the log, and still ignored, which
is what lrzsz does too.

Verified: with Escape8thBit=true still present in sexyz.ini the ZRINIT
now reads ZF0=0x23 with the ESC8 bit clear, and zmtx 2.04 -- which
honours the request and previously aborted 766,470 bytes in -- transfers byte-identically. Error-recovery gates at 3e-6 remain 3 of 3 receiving
and 3 of 3 sending.

Documented in docs/sexyz.txt, the release notes, and the wiki. GitLab
issue #1229.

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