It's possible that some values (e.g. "16384P") exceed the storage (count of
bytes) of a 64-bit integer, and such values were causing floating point
exceptions when running sbbsctrl.exe, e.g.
Faulting application name: sbbsctrl.exe, version: 3.20.0.0, time stamp:
0x00000000
Faulting module name: gdi32full.dll, version: 10.0.19041.2604, time stamp:
0x2b5302d5
Exception code: 0xc0000090

but interesting (and perhaps a clue), not with sbbs.exe.

Anyway, this added range checking, limiting the maximum value to INT64_MAX
(after division by unit, though there was no division-unit in the problem
case, the "min_dspace" value parsing in scfglib2.c). Using conditional/ternary
return statement had the same floating point exception occurrences, so this
if-statement shouldn't be removed/changed/optimized!

I suspect this has something to do with mix of Borland and MSVC run-time libs
and perhaps different expectations or setups with regards to floating point
exceptions. I did notice that when stepping through read_file_cfg(), I would
get different return values for the same call to iniGetBytes() depending on
whether it was initiated from sbbsctrl.exe (built with C++Builder) or
sbbs.dll (built with MSVC).

Thanks to Codefenix for providing the sample file.ini file that demonstrated
the issue. This problem would've been very hard to root-cause otherwise!