bug: normalize integer configuration before publishing to integer variables #532

Goal

normalize integer configuration before publishing to integer variables.

Background and evidence

Release-preparation review of a90aa1429647b6eb4820a01aabe37799ca55ad5e on macOS arm64. Bash 5.3.20; ordinary local POSIX filesystem.

base_app_config_load accepts decimal-looking values such as 010, 08, and 18446744073709551616. base_app_config_get then passes the raw string to printf -v for a caller-declared -i output. Bash evaluates it as arithmetic, causing inconsistent values, overflow, or terminating the shell.

source lib/bash/std/lib_std.sh
base_std_import app/lib_app.sh
base_app_init demo
base_app_config_define demo count integer
base_app_config_load demo --cli count=010
value=''; declare -i number=99
base_app_config_get demo count value
base_app_config_get demo count number
printf 'scalar=%s integer=%s\n' "$value" "$number"

Actual: scalar=010 integer=8. Loading count=08 succeeds but getting it into an integer emits value too great for base and exits a non-interactive Bash subprocess before subsequent statements. Loading 18446744073709551616 and getting into an integer silently yields 0 on this 64-bit host.

The README explicitly supports ordinary and integer scalar outputs for integer-typed config. The existing output-attribute tests do not exercise leading zeros, the signed range boundary, or overflow.

Scope and acceptance criteria

• Define the integer domain and use decimal normalization before arithmetic assignment.
• Reject out-of-range inputs recoverably before publication, or explicitly support arbitrary precision only where the destination can represent it.
• Keep outputs unchanged on rejected values and preserve the previous successful config snapshot on load failure.
• Add tests for 0, negative values, 010, 08/09, signed boundaries, oversized values, and both scalar/-i destinations in subprocesses that must remain alive.

Validation

Run focused app/std BATS, Bash 4.2/current option probes, and full validation. Reuse the existing decimal-validation machinery where appropriate.

Source references:

• lib/bash/app/lib_app.sh
• lib/bash/app/README.md
• lib/bash/app/tests/lib_app.bats
• lib/bash/std/lib_std.sh

Additional std validation evidence from release review

The shared decimal validator also wraps before checking ranges, independently of config publication. On the same reviewed commit and Bash 5.3.20:

source lib/bash/std/lib_std.sh
declare -a app_args=()
base_init app_args --source /tmp/range-probe.sh --
value=18446744073709551617
base_std_assert_integer_range value 1 10
printf 'status=%s value=%s\n' "$?" "$value"

Actual: status=0 value=18446744073709551617. This out-of-range value is converted to 1 by signed machine arithmetic and incorrectly accepted. __base_bash_libs_std_decimal_integer_value__ performs $((10#digits)) without first checking representability; base_std_assert_integer_range uses that converted value for its bounds check.

Include the shared std validator in this fix rather than relying on it unchanged: check the chosen integer domain before arithmetic conversion, test overflowing values and bounds (positive and negative), retain leading-zero decimal handling, and document the supported domain. Add a direct range-assertion regression alongside the app config scalar/integer publication cases. Existing in-range and reversed-bound regressions do not exercise machine overflow.

Source: shared conversion, range assertion.

Non-goals

No release publication or unrelated API redesign. Preserve documented compatibility except for the defective behavior identified above.

Project fields

• Project: base-bash-libs
• Status: Ready
• Priority: P2
• Area: Shell
• Initiative: Adoption Polish
• Size: M
• Milestone: v2.2.0

Agent assignment

Assignee: @codeforester. Implementation may be handled through the normal issue-backed worktree and reviewed PR workflow.