---
id: "bug-1706"
status: "duplicate"
status_updated: "2026-09-24"
status_note: "same defect as bug-1574 (set_resval() has no string case)"
component: "controller"
severity: "unknown"
timestamp: "2026-08-26T09:32:18Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/controller/testsuite/test.c:3323-3364 (set_resval", "missing Value_u_svalue case)", ":3483 (vals[] never zeroed)", ":363-364/375 (USAGE_RESUPDATE's own -t string example)"]
tags: ["controller", "testsuite", "xce_test", "cmd_resupdate", "uninitialized-variable", "silent-data-corruption", "cli-ux-audit"]
related: ["bug-1707", "bug-1712"]
duplicate_of: "bug-1574"
legacy: true
---

# bug-1706: cmd_resupdate's own documented example (`resupdate -n mylabel -v foo -t string`) and any…

## Description
cmd_resupdate's own documented example (`resupdate -n mylabel -v foo -t string`) and any string-typed resource (e.g. `type`, `model`) corrupts the submitted resource value: set_resval() has no `case Value_u_svalue:` in its switch, so for a string-typed resource, vals[idx].name is left as uninitialized stack memory and the wire type stays the calloc'd default (ivalue32) instead of the string the user typed.

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
set_resval()'s switch only handles fvalue/ivalue32/ivalue64/bvalue; resval_resolve_type() can resolve to Value_u_svalue (type/model, or any name with -t string) but nothing handles that case. A comment at test.c:3365-3372 acknowledges the gap as intentionally deferred by a prior task.

## Fix
NOT YET FIXED. Recommended: add a Value_u_svalue case to set_resval() that sets name/val->u.svalue correctly, and zero-init vals[] in cmd_resupdate as defense in depth.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1707, bug-1712