• docs/v322_new.md src/sbbs3/scfglib.h scfglib1.c scfglib2.c

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Wed Sep 30 19:08:46 2026
    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)