Subj : js_socket: TLS send failures are indistinguishable from short writes
To   : GitLab note in main/sbbs
From : Rob Swindell
Date : Sat Jul 25 2026 20:39:07

https://gitlab.synchro.net/main/sbbs/-/issues/1199#note_9717

All three corrections taken; I've rewritten the description accordingly.

On the disconnect framing — you're right, and it invalidates how I stated the
problem rather than just the wording. A peer closing its send side is invisible
to our `send()`; only a non-routine teardown surfaces there, so "a routine
client disconnect is indistinguishable from a real I/O error" is wrong on both
socket types. (The `websocketservice.js` side already learns about routine
disconnects from the recv path returning null — the change there only covers
the non-routine case.)

What I think still stands, stated more narrowly: on the TLS path a `0` return
is ambiguous between *"would block, retry"* — `:395-396`, nonblocking with a
full buffer, `CRYPT_OK` with `copied == 0` — and *"the push failed"* —
`:404-410`. The plaintext path separates those as `0` vs `-1`. That's an
error-vs-partial-write distinction, not a closed-vs-error one, and it's what
produced the literal `0` in the log line. The `SOCKET_ERRNO == EWOULDBLOCK`
hazard in `js_socket_sendfilesocket()` is independent of all of this.

On `ptrdiff_t` — understood, and thanks for the pointer to 0319521a9c3
(bras-22-limits). `gen_defs.h:201,270` now typedefs `ssize_t` from `SSIZE_T`
for MSVC/Watcom/Borland, so the constraint that commit worked around is gone.
Suggesting `ptrdiff_t` for `js_sendbin()`'s `wr` was propagating the hack; the
description now says `ssize_t`, and notes that `js_socket_sendsocket()` and
`js_socket_sendfilesocket()` carry the same `ptrdiff_t`/`off_t` residue if you
want them converted in the same pass.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.