Fix out of bounds read in formatString() on a trailing bare '%'

[sclaiborne]

Problem

formatString() consumed the character after % with switch (*(++src)). When the % was the last character before the terminator, that read yielded '\0', fell through to default:, and did src++ — advancing the source pointer past the null terminator. The enclosing while ((*src != '\0') && (destSize > 0)) then read out of bounds and kept copying until it happened to land on a zero byte.

Reproduce: formatString(dest, sizeof(dest), "value: %", &args) with any non-NULL pArguments.

This is reachable from application code — LogThat passes a user-supplied message string to formatString() (LogInternalWrite.c), and a stray trailing % in an operator-facing log message is realistic input.

Fix

Advance the pointer explicitly and break out of the loop when the % has no command character after it:

// Consume the char and investigate the command
src++;

// A '%' at the very end of the source has no command character.
// Stop here so the cases below never step past the terminator.
if (*src == '\0')
	break;

switch (*src)

The break exits the enclosing while, so the function falls through to *dst = '\0' and returns the length written so far. "value: %" now yields "value: " — the stray % is dropped, consistent with how default: already discards unknown specifiers.

The other case bodies do src++ only after *src matched a real (non-NUL) command character, so the single guard before the switch covers all of them. No other pointer-advance site in the library has this pattern.

Regression test

Follows the existing hexTest shape in the AS6 example project — a table-driven self test gated by a BOOL, with pass/fail counters and the first failing input.

• formatTest, formatTestPass, formatTestFail, formatTestFirstFail in Variables.var
• runFormatTest() in Main.c, called from ProgramCyclic on a rising edge

Each case's format is copied into a 64-byte scratch buffer pre-filled with 'X', so the bytes after the terminator are junk. Under the old code, "value: %" dragged that filler into the destination; the expected-output compare catches it.

Cases cover the four trailing-% variants ("value: %", "%", "trail %d%", "%%%"), ordinary %d/%s/%b substitution, %%, an unknown specifier, the three NULL-pointer inputs, and two truncation cases where a trailing % lands with no room left.

Verification

No host C compiler is available on the dev machine (only "Automation Studio Code" is installed, no BR.AS.Build.exe), so the self test has not been run on hardware yet. Expected values were validated by porting formatString line-for-line to a throwaway model and running the table against it — all ten table cases and both truncation cases match. CI builds Intel and ARM on the AS6 runner for this PR.

🤖 Generated with Claude Code