Parent epic: #254
Surfaced by CodeRabbit during the S23.09 platform-header docs (PR #607):
#607 (comment)
(re-raised: #607 (comment))
The gap
SolidSyslogFreeRtosSysUpTime_Get is
(uint64) xTaskGetTickCount() * 100 / configTICK_RATE_HZ cast to uint32.
xTaskGetTickCount() is the raw FreeRTOS tick counter, which wraps at its own
width (2^32 ticks ~= 49.7 days at 1 kHz; far sooner under
configUSE_16_BIT_TICKS). At that wrap the reported uptime jumps backwards and
resets well before the RFC 3418 modulo-2^32 hundredths period.
Only the FreeRtos implementation is affected: Posix (CLOCK_BOOTTIME) and Windows
(GetTickCount64) are real since-boot counters whose RFC 3418 claims are accurate.
Options (to decide here)
- Compile-time guard (preferred / David's instinct). A
#error /
_Static_assert that fails the build when the tick width cannot back a faithful
32-bit TimeTicks (e.g. configUSE_16_BIT_TICKS, or a tick rate that makes the
scaled wrap period too short), with a comment telling the integrator how to
become compliant (use a 32-bit TickType_t, or opt into the extension below).
Refuses to silently ship a subtly-wrong uptime; the integrator makes an
informed choice.
- Overflow extension. Track tick overflows (a wrap counter maintained against
a stored last-tick) to extend the base to a monotonic 64-bit tick count before
scaling — then the uint32 result wraps correctly per TimeTicks on every
config.
- Accept + document. Ship as-is with the limitation documented (current
interim state).
Amend the doc when fixed
The SolidSyslogFreeRtosSysUpTime_Get doc-comment was softened in PR #607 to
"...not a full TimeTicks counter" as an interim. When the fix lands (guard
and/or extension), update that comment to state the new contract — e.g. "RFC 3418
compliant; a #error guards unsupported tick configs."
Done when
- Either uptime is monotonic to the full RFC 3418 range (extension) or an
unsupported tick config fails to compile (guard), and the
SolidSyslogFreeRtosSysUpTime_Get doc-comment is updated to match.
Parent epic: #254
Surfaced by CodeRabbit during the S23.09 platform-header docs (PR #607):
#607 (comment)
(re-raised: #607 (comment))
The gap
SolidSyslogFreeRtosSysUpTime_Getis(uint64) xTaskGetTickCount() * 100 / configTICK_RATE_HZcast touint32.xTaskGetTickCount()is the raw FreeRTOS tick counter, which wraps at its ownwidth (2^32 ticks ~= 49.7 days at 1 kHz; far sooner under
configUSE_16_BIT_TICKS). At that wrap the reported uptime jumps backwards andresets well before the RFC 3418 modulo-2^32 hundredths period.
Only the FreeRtos implementation is affected: Posix (
CLOCK_BOOTTIME) and Windows(
GetTickCount64) are real since-boot counters whose RFC 3418 claims are accurate.Options (to decide here)
#error/_Static_assertthat fails the build when the tick width cannot back a faithful32-bit
TimeTicks(e.g.configUSE_16_BIT_TICKS, or a tick rate that makes thescaled wrap period too short), with a comment telling the integrator how to
become compliant (use a 32-bit
TickType_t, or opt into the extension below).Refuses to silently ship a subtly-wrong uptime; the integrator makes an
informed choice.
a stored last-tick) to extend the base to a monotonic 64-bit tick count before
scaling — then the
uint32result wraps correctly per TimeTicks on everyconfig.
interim state).
Amend the doc when fixed
The
SolidSyslogFreeRtosSysUpTime_Getdoc-comment was softened in PR #607 to"...not a full TimeTicks counter" as an interim. When the fix lands (guard
and/or extension), update that comment to state the new contract — e.g. "RFC 3418
compliant; a
#errorguards unsupported tick configs."Done when
unsupported tick config fails to compile (guard), and the
SolidSyslogFreeRtosSysUpTime_Getdoc-comment is updated to match.