Skip to content

Fix address-truthiness bugs around a valid 0x0 - #1

Open
ppannuto-claude wants to merge 1 commit into
ppannuto:masterfrom
ppannuto-claude:fix/local-board-zero-address
Open

Fix address-truthiness bugs around a valid 0x0#1
ppannuto-claude wants to merge 1 commit into
ppannuto:masterfrom
ppannuto-claude:fix/local-board-zero-address

Conversation

@ppannuto-claude

@ppannuto-claude ppannuto-claude commented Sep 1, 2026

Copy link
Copy Markdown

Summary

Several places in tockloader distinguish "no address given/known" from
"an address was given/known" using plain truthiness (if addr:) on a
value that is None when unset. That conflates "unset" with an address
of exactly 0x0, which is a normal, valid flash and/or app base address
(e.g. any Cortex-M board, or Tock's qemu_arm_mps2 boards) — found
while getting qemu_arm_mps2 working with tockloader local-board.

Fixed all instances of this pattern to check is not None instead:

  • main.py command_local_board_set(): an explicit --app-address 0x0/--flash-address 0x0 was validated but then silently omitted
    from the status output, making it look like the flag was ignored.
  • flash_file.py set_local_board(): the same values were then
    silently dropped from the persisted local-board TOML config,
    discarding the deliberate setting entirely.
  • flash_file.py FlashFile.get_flash_address(): a stored
    flash_address == 0 was reported as None (unknown) instead of 0.
  • board_interface.py BoardInterface.get_apps_start_address(): a
    configured app_address == 0 was ignored in favor of querying the
    board's appaddr attribute (or returning None if that's absent).
  • tockloader.py _get_apps_start_address(): a cached value of 0,
    an explicit --app-address 0x0 on any command (not just
    local-board set), or a channel-reported address of 0 were all
    treated as "unknown" and silently overridden by lower-priority
    defaults.
  • tockloader.py _get_flash_start_address(): a channel-reported
    flash address of 0 was treated as "unknown" and replaced with the
    function's own hardcoded 0 default -- harmless today only because
    that default happens to also be 0.
  • tockloader.py _get_memory_start_address(): same cached-value
    pattern as above, for the app RAM start address.

Note: a related but distinct bug in _reshuffle_apps() (a debug-log
format string crashing on a None RAM address) is being tracked
separately upstream as tock#141 and is not part of this PR.

Test plan

  • python3 -m tockloader.main local-board set zerotest --arch cortex-m3 --app-address 0x0 --flash-address 0x0 — confirmed both
    values now appear in the status output and are correctly
    persisted as 0 (not omitted) in the TOML config.
  • No project test suite exists to run (CI only builds + smoke-tests
    --version/list-known-boards). The remaining sites
    (_get_apps_start_address, _get_flash_start_address,
    _get_memory_start_address, get_apps_start_address) were
    reviewed by inspection and are the same fix pattern, but not
    individually exercised against real hardware/QEMU in this
    session.

AI use disclosure

This PR was written primarily by Claude Code (Anthropic's Claude Sonnet
5). Claude was given a human-authored bug report describing the
original local-board truthiness bug with exact file/line locations,
then asked to audit the rest of the codebase for the same bug class,
which surfaced the additional sites above; a human then directed which
fixes to apply and how to structure the commit. Reviewed by the
submitter before opening/updating.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

🤖 Generated with Claude Code

https://claude.ai/code/session_01KTQ6pWrckM3jp9vfBo4bhk

Several places in the codebase distinguish "no address given/known"
from "an address was given/known" using plain truthiness (`if addr:`)
on a value that is `None` when unset. That conflates "unset" with an
address of exactly `0x0`, which is a normal, valid flash and/or app
base address (e.g. any Cortex-M board, or Tock's qemu_arm_mps2 boards).
Fix all of these to check `is not None` instead:

- `main.py` `command_local_board_set()`: an explicit `--app-address
  0x0`/`--flash-address 0x0` was validated but then silently omitted
  from the status output, making it look like the flag was ignored.
- `flash_file.py` `set_local_board()`: the same values were then
  silently dropped from the persisted `local-board` TOML config,
  discarding the deliberate setting entirely.
- `flash_file.py` `FlashFile.get_flash_address()`: a stored
  `flash_address == 0` was reported as `None` (unknown) instead of `0`.
- `board_interface.py` `BoardInterface.get_apps_start_address()`: a
  configured `app_address == 0` was ignored in favor of querying the
  board's `appaddr` attribute (or returning `None` if that's absent).
- `tockloader.py` `_get_apps_start_address()`: a cached value of `0`,
  an explicit `--app-address 0x0` on any command (not just
  `local-board set`), or a channel-reported address of `0` were all
  treated as "unknown" and silently overridden by lower-priority
  defaults.
- `tockloader.py` `_get_flash_start_address()`: a channel-reported
  flash address of `0` was treated as "unknown" and replaced with the
  function's own hardcoded `0` default -- harmless today only because
  that default happens to also be `0`.
- `tockloader.py` `_get_memory_start_address()`: same cached-value
  pattern as above, for the app RAM start address.

Verified with `local-board set zerotest --arch cortex-m3
--app-address 0x0 --flash-address 0x0`: both values now appear in the
status output and are correctly persisted as `0` (not omitted) in the
TOML config.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KTQ6pWrckM3jp9vfBo4bhk
@ppannuto-claude
ppannuto-claude force-pushed the fix/local-board-zero-address branch from d3ff1a2 to 654fa20 Compare September 1, 2026 19:11
@ppannuto-claude ppannuto-claude changed the title Fix two zero-flash-address bugs in local-board Fix address-truthiness bugs around a valid 0x0 Sep 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant