Subj : docs/v322_new.md src/sbbs3/scfglib.h scfglib1.c scfglib2.c
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Wed Sep 30 2026 19:08:47

https://gitlab.synchro.net/main/sbbs/-/commit/7506ebb01d65da5952a58c26
Modified Files:
	docs/v322_new.md src/sbbs3/scfglib.h scfglib1.c scfglib2.c
Log Message:
Config loading: warn when an .ini string value doesn't fit its field

Every string read from ctrl/*.ini into a fixed-size scfg_t field went
through SAFECOPY(), which cuts silently. A value longer than its field
(a 101-character external program command line, say) was simply lost
past the limit, with nothing in any log, and the resulting behavior had
to be reverse-engineered: a scratch external configured with a 103-char
command ran without its trailing %n argument. Values reach those files
by many paths (SCFG, scripts, hand editing, other tools), so SCFG's own
input limit is not the only one in play.

Add scfg_ini_get_str() and its INI_GET_STR() macro, which do the
iniGetString() lookup and the copy into the field, and log a warning
naming the key, the limit and the whole value when it had to be
truncated, and move the 137 copy sites in scfglib1.c and scfglib2.c
onto it (each now names its key once). Every program that links the
config readers already supplies the lprintf() that load_cfg.c and
readtext.c require, so there is no new link requirement.

Verified by loading a scratch config with that 103-character command:
"!Config value 'cmd' truncated from 103 to 100 chars: ..." is logged
once, and the build is warning-free.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
--- SBBSecho 3.38-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.