Subj : docs/v322_new.md src/sbbs3/chksmb.c writemsg.cpp src/smblib/smbadd.c s
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Tue Sep 15 2026 20:47:46

https://gitlab.synchro.net/main/sbbs/-/commit/b7f7d2b3f506c3e449640733
Modified Files:
	docs/v322_new.md src/sbbs3/chksmb.c writemsg.cpp src/smblib/smbadd.c smballoc.c smbdefs.h smblib.h smbtxt.c
Log Message:
smblib: raise the message data storage ceiling from 2GB to 4GB

smb_allocdat() and smb_fallocdat() validated a data offset by testing
(int)offset < 0, truncating a 64-bit off_t to 32 bits. Every allocation
at or above 2GB read as negative and was refused with SMB_ERR_DAT_OFFSET,
so a .sdt file could not grow past 2GB even though the format stores that
offset in a uint32_t and so reaches 4GB - 1.

The same truncation failed open at the top: at exactly 4GB, (int)offset
is 0 and passes, and the header is then written with
(uint32_t)4294967296 == 0, leaving the message's data at 4GB and its
header pointing at the start of the file.

Bound the end of the allocation against the format's own limit instead,
named SMB_MAX_DAT_OFFSET/SMB_MAX_HDR_OFFSET, and repeat the check in
smb_addmsg() where the offset is narrowed to uint32_t, which is the only
guard for a hyper-allocated base. The data-length limit smb_addmsg()
already enforced becomes SMB_MAX_DAT_LEN.

Offsets on the way there were themselves 32-bit: ftell() is a 32-bit long
on Windows, chsize() arguments were cast to int (one an int * int
multiply that overflows at 2GB while truncating the data file), and the
message text was read with a bare fseek() of hdr.offset + dfield.offset
computed in 32-bit unsigned arithmetic.

issue #12

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.