Please describe the feature you'd like to see added.
When a config file provides an integer or boolean option with an empty value (e.g. maxconnections=) or a non-numeric value (e.g. maxconnections=abc), Bitcoin Core should surface a visible, human-readable startup warning (and ideally log the config line number), rather than silently parsing the value as 0. The intent is to make malformed config values fail loudly instead of quietly changing node behaviour.
Is your feature related to a problem, if so please describe it.
Yes. Config values are currently parsed silently, with no sanity feedback:
- A single stray line maxconnections= in bitcoin.conf is accepted without any warning.
- ArgsManager::SettingTo<Int> (src/common/args.cpp:556-563) falls through to LocaleIndependentAtoi<Int>(""), which yields 0 (the parse-success bool is discarded; see src/common/args.cpp:43-49).
- GetIntArg("-maxconnections", …) returns 0, and src/init.cpp:814-820 then treats -maxconnections <= 0 as "disable networking", silently flipping -dnsseed=0 and -listen=0. The result is that a node starts, never DNS-seeds, and never listens, with nothing more than a normal "parameter interaction" info log — very hard to diagnose, and surprising because the user never wrote an explicit 0. The same silent-0 substitution affects every integer/bool option (rpcworkqueue=, limitancestorcount=, par=, mempoolexpiry=, …), and maxconnections=abc behaves identically to maxconnections=. This is a robustness/usability gap, not a crash — it is the "empty or typo'd value" companion to the surrounding config-overflow issues (stray or malformed input silently changing the effective configuration).
Describe the solution you'd like
- Primary (recommended, backwards-compatible): in ArgsManager::SettingTo<Int> (src/common/args.cpp:556-563), when a supplied string value is empty or fails LocaleIndependentAtoi, emit a one-time startup warning before returning 0, e.g.: Warning: option 'maxconnections' has an empty/invalid value and is being ignored (bitcoin.conf:1). Did you mean maxconnections=0? Warnings should be accumulated and printed during AppInitMain, matching how other startup warnings are surfaced, and preserved for valid inputs.
- The guard must fire only on malformed values: explicit, documented zero semantics stay untouched (maxconnections=0, listen=1, -maxmempool=0) must produce no false-positive warning.
Describe any alternatives you've considered
- Strict reject (parse error): treat empty/non-parseable values for registered options as a fatal startup error in src/common/config.cpp. This is the clearest, but it is a bigger breaking change and would need a whitelist to keep legitimate =0 forms working. I considered this a "stricter, later" option.
- No change (status quo): keep atoi-compatibility. Rejected because the silent behavioural flip (especially the maxconnections= → "no networking" case) is a real support/diagnosability burden with essentially no compatibility upside.
- Documentation-only: clarify the help text that empty values mean 0. Insufficient on its own it does not prevent the accidental maxconnections= case.
Please leave any additional context
- Relevant code:
- src/common/args.cpp:556-563 — SettingTo<Int> silently maps empty/bogus strings → 0.
- src/common/args.cpp:43-49 — documented "non-numeric input → value 0" semantics.
- src/common/config.cpp:63-67 — empty values after = are stored unvalidated.
- src/init.cpp:814-820 — the -maxconnections <= 0 interaction that flips -dnsseed/-listen off.
- Verified on master@c4fbd3c (this repo), by reading the parsing/validation chain. No live node was run, so the exact proposed warning text is illustrative.
- Affects every numeric/bool option parsed via GetIntArg/GetBoolArg from a config file, not just networking ones.
- Acceptance criteria: maxconnections= or maxconnections=abc in a config produces a visible warning and no longer silently disables dnsseed/listen; maxconnections=0 keeps its documented behaviour with no false positive; all existing test/functional/ and src/test/argsman_tests.cpp cases still pass for well-formed configs.
- Open question for maintainers: warn (recommended) vs reject.
